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I.   OBJECTIVE  AND  SCOPE  OF  WORK 


The  objective  of  this  project  is  to  develop  a  computer 
based  process  simulator  and  economic  evaluation  system  for  use 
in  the  engineering  of  fossil  energy  conversion  processes.  The 
system  has  been  named  ASPEN  (Advanced  System  for  Process  Engi- 
neering). It  will  provide  the  U.S.  Department  of  Energy  (DOE) 
and  its  contractors  with  a  rapid,  efficient,  and  consistent 
means  of  performing  its  process  evaluation  functions. 

ASPEN  will  be  capable  of  performing  detailed  material  and 
energy  balances,  equipment  sizing,  and  economic  evaluation  for 
processes  such  as  coal  gasification  and  liquefaction.   It  will 
be  designed  to  meet  the  specialized  requirements  of  fossil 
energy  conversion  processes,  including  an  extensive  data  base 
for  coal  physical  properties,  compatibility  with  conversion 
reactor  models  currently  available  and/or  being  constructed, 
and  the  capability  of  handling  streams  containing  solids. 

The  scope  and  specific  objectives  of  the  project  are  to: 
1.   Develop  a  prototype  simulator  and  demonstrate  the  ability 

to  simulate  three  specific  fossil  fuel  conversion 

processes  of  interest  to  DOE  (HYGAS,  Donor  Solvent,  and 

CO^  Acceptor) . 


8. 


Develop  a  system  structure  of  ASPEN  with  the  necessary 
flexibility  to  model  the  different  process  configurations 
encountered  in  fossil  energy  processes  and  to  allow  inser- 
tion of  proprietary  programs  and  data. 

Develop  a  physical  property  subsystem  that  will  calculate 
the  properties  important  in  modeling  fossil  energy  pro- 
cesses.  It  will  have  an  associated  data  base  for  coal 
physical  properties. 

Develop  a  unit  operations  subsystem  which  will  have 
process  models  for  all  major  types  of  equipment  used  in 
fossil  fuel  conversion  processes. 

Develop  a  cost  estimation  and  economic  evaluation 
subsystem  that  will  compute  capital  investment,  operating 
costs,  and  profitability  of  proposed  designs. 
Develop  a  data  regression  subsystem  that  will  utilize 
experimental  data  to  compute  coefficients  in  correlations 
for  physical  properties. 

Acquire  existing  industrial  programs  and  data  and  modify 
them  for  incorporation  into  ASPEN.   This  will  avoid  the 
need  to  redevelop  existing,  standard  routines  for  modeling 
unit  operations,  physical  properties,  and  other  calcula- 
tions. 

Demonstrate  the  capabilities  of  ASPEN  by  simulating  a 
number  of  benchmark  problems. 


II.   SUMMARY  OF  PROGRESS  TO  DATE 

PUBLICATIONS 
The  year's  work  has  resulted  in  the  publication  of  the 
following  reports,  theses,  etc.  in  addition  to  the  three 
quarterly  progress  reports. 

1.   Armar,  A.,  "Computer-Aided  Cost  Estimation  Systems",  M.S. 
Thesis,  Department  of  Chemical  Engineering,  M.I.T., 
1978. 


2. 


Boston,  J.  P.,  Britt  H.  I.,  "A  Radically  Different 

Formulation  and  Solution  of  the  Single-stage  Flash 
Problem",  Energy  Laboratory,  M.I.T.   To  be  published 
in  "Computers  and  Chemical  Engineering." 


3.   Evans,  L.  B. ,  Joseph,  B.,  Seider,  W.  D. ,  "System  Structures 
for  Process  Simulation,"  published  in  the  AIChE 
Journal  (Vol.  23,  No.  5),  September,  1977. 


4.   Garcia-Gamboa,  E. ,  "Estimation  of  Physical  Properties  of 
Coal  Derived  Liquids."  M.S.  Thesis,  Department  of 
Chemical  Engineering,  M.I.T. ,  August,  1977. 


5.  Greenberg,  R.  J.,  "Computer  Implementation  of  Algorithm  to 

Find  Recycle  Loops  and  Tear  Streams",  B.S.  Thesis, 
Department  of  Chemical  Engineering,  M.I.T.,  June,  1978 

6.  Neville,  J.M. ,  "Simulation  of  the  C02-Acceptor  Process  for 

Coal  Gasification,"  M.S.  Thesis,  University  of 
Pennsylvania,  Philadelphia,  PA.  1978. 

7.  Tsang,  M. ,  "Physical  Property  Constant  Estimation  of  Coal 

Liquids,"  B.S.  Thesis,  Department  of  Chemical 
Engineering,  M.I.T.,  May,  1978. 

8.  Wei,  S.H.,  "Simulation  of  Heat  Exchangers  and  Reactors," 

M.S.  Thesis,  Department  of  Chemical  Engineering, 
M.I.T.,  June,  1978. 

9.  White,  G.L.,  "Simulation  of  the  HYGAS  Coal  Gasification 

Process",  M.S.  Thesis,  Department  of  Chemical 
Engineering,  M.I.T.,  June,  1977. 


10.  White,  G. ,  B.  Joseph  and  L.B.  Evans,   "Simulation  of  a  Coal 
Gasification  Process,"   Paper  presented  at  the  70th 
Annual  Meeting  of  the  AIChE  at  New  York,  November, 
1977. 


TASK  SUMMARIES 

The  work  und^r  contract  No.  E(49-18) -2295  Task  No.  9  is 
organized  into  eight  reporting  tasks.   Summaries  of  work 
accomplished  in  these  tasks  appear  in  this  section,  for  the 
period  June  1,  1977  to  May  31,  1978. 

TASK  1:   DEVELOPMENT  OF  PROTOTYPE  COMPUTER  SIMULATOR  AND 
SIMULATION  OF  SPECIFIC  FOSSIL  ENERGY  PROCESSES 

Simulation  of  the  HYGAS  coal  gasification  process,  using 
the  prototype  process  simulator  PLEXSYS  II,  has  been  com- 
pleted.  Models  of  the  major  process  units  necessary  to 
simulate  the  HYGAS  process  were  developed.   The  preliminary 
Physical  Property  System  (PPS)  was  used  to  estimate  property 
values  for  solids,  liquids,  gases,  and  their  mixtures.   Sec- 
tions of  the  HYGAS  process  were  simulated  individually  and  the 
sections  were  also  combined  in  simulation  studies  of  the  whole 
plant.   Sensitivity  studies  of  the  effects  of  varying  split 
fractions  in  the  methanation  section  were  also  carried  out. 
The  PLEXSYS  II  system  proved  highly  flexible  and  quite  capable 
in  handling  the  process  simulation. 
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The  CO2  Acceptor  Process  has  been  simulated  in  two 
parts.   Simulation  of  the  pretreatment  section  of  the  process 
was  completed  under  a  subcontract  at  the  University  of  Penn- 
sylvania and  the  gasification  section  of  the  pilot  plant  was 
simulated  at  M.I.T.   Under  the  pretreatment  section,  simula- 
tion, models  for  the  crusher,  hot  gas  swept  hammer  mill, 
fluidized  bed  preheater/dryer,  cyclone  separator  furnace,  and 
flash  dryer  were  formulated.   The  programs  for  these  models 
were  written  and  tested  with  available  data.   Under  the  gasifi 
cation  section  work,  four  pilot  plant  runs  were  simulated  and 
the  simulation  results  are  presented  in  this  report.   The  plex 
data  structure  and  routing  features  for  the  calculations 
allowed  great  flexibility  in  the  handling  of  process  streams 
containing  multiple  phases  of  gases,  liquids,  and  solids. 
Results  of  the  simulation  study  compared  well  with  several 
sets  of  pilot  plant  data.   The  sensitivity  of  the  process  to 
key  variables  was  studied.   These  results  show  how  an  advanced 
process  simulator  can  be  used  to  simulate  coal  conversion 
processes  involving  solids  as  well  as  traditional  gas  and 
liquid  phases. 

Progress  on  the  simulation  of  the  Exxon  Donor  Solvent  coal 
liquefaction  process  was  delayed  by  the  lack  of  access  to  pro- 
prietary data  and  publicly  available  data  up  to  this  time.  An 
agreement  has  been  reached  with  Exxon  to  obtain  some  of  the 


proprietary  data  on  the  process  and  we  have  obtained  the 
published  reports  from  Exxon  which  were  only  recently  cleared 
for  release.   It  has  been  decided,  however,  that  the  EDS 
process  will  be  a  benchmark  problem  for  ASPEN  to  be  studied 
under  Task  8  rather  than  duplicating  more  work  under  the 
prototype  PLEXSYS  simulator. 

Thus,  the  work  on  Task  1  has  been  completed. 


TASK  2:   DEVELOPMENT  OF  ASPEN  SYSTEM  STRUCTURE 

The  design  of  ASPEN  was  completed  during  the  past  year. 
The  major  steps  in  the  design  were  (1)  the  preparation  of  a 
set  of  design  criteria,  (2)  the  preparation  of  the  functional 
specifications,  and  (3)  the  structured  design  of  the  system 
based  on  the  functional  specifications.   A  document  entitled 
Functional  Specifications  of  ASPEN  was  issued  during  the  second 
quarter.   The  main  effort  during  the  last  quarter  was  on  the 
design  specifications.   This  work  has  now  been  completed.   The 
System  Design  Task  Force  of  the  Advisory  Committee  met  on  May 
1  and  2  and  reviewed  the  design  of  the  system.   A  document 
entitled  Design  Specificaton  of  ASPEN  has  been  completed  and 
will  be  published  as  an  Appendix  to  this  report  as  a  separate 
volume. 

Since  this  task  has  been  completed  there  is  no  work 
forecast  under  this  task  for  the  next  quarter. 
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TASK  3:   DEVELOPMENT  OF  PHYSICAL  PROPERTY  SYSTEM 


The  major  activities  during  the  past  year  have  been  the 
preparation  of  the  Functional  and  Design  Specifications.   Other 
activities  included  the  development  of  coal  liquid  property 
models,  a  survey  and  evaluation  of  property  constant  estimation 
methods,  and  a  study  of  activity  coefficient  models  for  elec- 
trolytes. 

The  Functional  Specifications  were  documented  in  Appendix  I 
of  the  Sixth  Quarterly  Progress  Report,  and  are  summarized  in 
Section  3.1.1.   The  main  points  covered  in  the  summary  are: 

(1)  Overall  make-up  of  the  physical  property  system 

(2)  Pure  compound,  coal  and  other  data  banks 

(3)  Data  regression  subsystem 

(4)  Property  constant  estimation  subsystem 

(5)  Input  modes 

(6)  Property  calculation  subsystem 

(a)  Properties  calculated 

(b)  Property  models 

The  Design  Specifications  have  been  completed  for  all 
features  of  the  Physical  Property  System  (PPS)  to  be  included 
in  the  basic  version  of  ASPEN.   A  Data  Regression  Subsystem  and 
a  Data  File  Management  Subsystem  have  been  specified  for  data 
file  preparation  before  running  ASPEN.   For  the  input  trans- 
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lation  phase,  PPS  features  of  the  input  language,  the  input 
processor  (including  data  retrieved)  and  the  data  structures 
required  for  both  the  input  processing  and  simulation  phases 
have  been  designed.   The  physical  property  monitor  systems  that 
will  control  the  calculation  of  both  conventional  and  non- 
conventional  properties  during  the  simulation  phase  have  also 
been  designed. 

The  purpose  of  the  work  on  coal  liquid  property  models  was 
to  develop  correlations  capable  of  predicting  the  critical  tem- 
perature and  pressure,  molecular  weight,  normal  vaporization 
enthalpy,  and  acentric  factor  of  coal  liquid  cuts  as  functions 
of  API  gravity  and  normal  boiling  point.   The  correlations 
developed  in  this  work  represent  substantial  improvements  over 
previous  ones,  such  as  the  Cavett  and  Lee-Kesler  correlations. 

The  Property  Constant  Estimation  Subsystem  is  not  scheduled 
for  implementation  in  the  basic  version.   However,  much  of  the 
work  on  evaluating  the  selecting  estimation  methods  has  been 
completed.   The  results  are  reported  in  Section  3.1.4. 

The  work  on  electrolyte  activity  coefficient  models  was 
aimed  at  obtaining  a  model  that  will  be  valid  for  systems  con- 
taining both  weak  and  strong  electrolytes,  as  well  as  non- 
dissociating  molecular  species.   A  modified  form  of  Pitzer's 
equation  was  found  to  be  the  most  suitable  model.   Its  validity 
was  demonstrated  using  actual  data  for  the  aqueous  potassium 
carbonate-carbon  dioxide  system. 
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TASK  4:   DEVELOPMENT  OF  UNIT  OPERATIONS  SUBSYSTEM 


Work  on  the  Unit  Operations  Subsystem  is  divided  into  two 
parts:  system  design  and  development  of  process  models. 

An  especially  significant  design  requirement  for  a  fossil 
fuel  conversion  process  simulator  is  that  it  be  able  to  accom- 
odate streams  with  multiple  liquid  and  solid  phases  and  com- 
ponents not  characterized  by  pure  compounds  or  pseudo-compounds 

System  design  work  has  been  completed  for  the  following 
areas:  (1)  data  content  and  structure  for  models  and  streams, 
(2)  the  specification  of  how  models  interface  with  the  simula- 
tion executive  and  the  physical  property  subsystem,  (3)  the 
input  processing  of  model  and  stream  data,  (4)  how  model  calcu- 
lations are  controlled,  and  (5)  the  relationship  of  individual 
model  calculations  with  the  computational  architecture.   The 
unit  operations  design  is  essentially  complete  and  coding  will 
begin  this  next  quarter.   Coding  and  testing  of  programs  for 
the  basic  system  will  be  completed  the  following  quarter. 

The  first  step  in  model  development  was  to  determine  what 
specific  unit  operation  modeling  capabilities  ASPEN  should 
have.   The  next  step  was  to  determine  which  of  these  models  are 
available  in  FLOWTRAN,  which  models  should  be  purchased,  and 
which  models  should  be  developed  as  part  of  the  ASPEN  Project. 
These  steps  have  been  completed. 
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FLOWTRAN  has  been  acquired  and  a  plan  for  converting 
selected  FLOWTRAN  models  to  ASPEN  models  developed.   A  project 
to  evaluate  software  available  for  purchase  was  undertaken 
and  is  discussed  as  Task  7.   Several  projects  were  started  to 
develop  the  necessary  new  models  for  ASPEN.   The  areas  con- 
sidered were  coal  reactors,  solids  handling,  electrolyte 
systems,  rigorous  conventional  reactors,  and  multiple  phase 
and  chemical  equilibrium. 

Each  of  these  projects  has  resulted  in  the  specification 
of  models  for  ASPEN.   Coding  of  basic  system  models  will  begin 
next  quarter  in  parallel  with  the  systems  program  coding. 
During  the  remainder  of  the  project  additional  models  will  be 
specified  and  coded  as  required  for  the  benchmark  simulations. 


,r::i>:: 
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TASK  5:   DEVELOPMENT  OF  COST  ESTIMATION  AND  ECONOMIC  EVALUATION 
SUBSYSTEM 


Most  of  the  work  on  the  Cost  Estimation  and  Economic  Eval- 
uation Subsystem  has  been  concentrated  on  system  design  and 
functional  specifications.   The  subsystem  is  divided  into 
sizing  and  costing  blocks  for  individual  process  equipment  and 
an  economic  evaluation  block.   The  data  structure  and  program 
structures  have  been  defined  for  both  the  sizing  and  costing 
blocks  and  the  economic  evaluation  block.   Associated  with 
these  blocks,  the  data  structure  for  utility  data  blocks  and 
plant  section  data  blocks  have  been  defined.   The  plant  section 
blocks  are  used  to  store  cost  estimation  factors  for  the  plant 
section  to  increase  accuracy  for  capital  investment  estimates. 

During  the  next  quarter,  coding  of  the  the  basic  system 
will  be  completed.   In  addition,  study  on  sizing  and  costing 
methods  will  be  completed,  and  cost  data  will  be  collected  and 
stored  on  the  cost  data  file.   Also,  existing  proprietary  soft- 
ware for  the  ASPEN  Economic  Evaluation  Subsystem  will  be 
acquired  and  modified. 


m  I 


TASK  6:   DATA  REGRESSION  SUBSYSTEM 
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Three  nonlinear  regression  programs  were  evaluated. 
Several  test  problems  were  solved.   The  objective  is  to 
determine  which  of  these  programs  should  be  acquired  for 
ASPEN. 

During  the  next  quarter,  the  basic  version  of  the  Data 
Regression  Subsystem  will  be  implemented.   The  FLOWTRAN  VLS 
will  serve  as  a  basis  for  this. 
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TASK  7:   ACQUISITION  OF  PROPRIETARY  SOFTWARE  AND  MODIFICATION 
FOR  USE  IN  ASPEN 


2. 


3. 


The  FLOWTRAN  system  has  been  acquired  as  a  base  simulator. 
Delivery  of  FLOWTRAN  has  been  successfully  completed. 
Modification  of  FLOWTRAN  subsytems  for  use  in  ASPEN  will  be 
completed  by  the  end  of  September,  1978. 

Survey  and  testing  of  distillation/absorption  programs  has 
identified  specific  programs  that  ASPEN  should  acquire. 
Combined  together  these  programs  will  ensure 

1.    small  execution  times  for  rating  case  studies. 

a  capability  to  specify  distillation  system  variables 
and  solve  directly  for  them. 

solve  simultaneouly  distillation  (absorption, 
extraction)  towers  connected  by  recycle  loops. 

Examination  of  the  solids  handling  programs  has  shown  that 
ASPEN  can  not  use  any  of  the  existing  programs.   The  ASPEN 
staff  will  develop  its  own  solids-handling  models. 

Sizing  and  costing  programs  still  have  to  be  further 
evaluated  to  make  a  final  decision.   As  an  intial  set,  modules 
from  FLOWTRAN  will  be  used. 

During  the  past  year,  existing  cost  esimation  programs  were 
analyzed  and  evaluated  in  greater  detail  using  a  sample  problem 
of  coal  gasification  process.   The  IGT's  HYGAS  process  was 
chosen  as  a  sample  problem  for  the  evaluation.   In  addition, 


16 

after  a  thorough  literature  search  for  sizing  methods  for 
process  equipment  as  well  as  cost  estimation  and  economic 
evaluation  programs,  PEPCOST  (Stanford  Research  Institute)  and 
PROVES  (G.  Enyedy,  Jr.)  systems  were  determined  as  candidates 
for  the  cost  estimation  and  economic  evaluation  subsystem  in 
ASPEN.   Moreover,  several  modules  in  FLOWTRAN  for  sizing  and 
costing  can  be  used  for  the  basic  simulator. 

Thermodynamic  properties  systems  need  further  evaluation 
prior  to  making  a  final  decision. 


iV-y/f/A- 
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TASK  8:   INTEGRATION,  TESTING  AND  DOCUMENTATION  OF  ASPEN  SYSTEM 


Work  on  this  task  has  just  begun.   During  the  next  quarter 
most  of  the  basic  system  will  be  implemented  and  tested. 
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ASPEN  PROJECT  SCHEDULE 


As  this  summary  indicates  most  work  of  this  quarter  has 
been  concentrated  on  design.   With  the  design  work  about  95% 
completed  we  are  now  concentrating  on  program  implementation. 
In  addition  to  our  permanent  staff  of  eight  professionals  and 
nine  research  assistants  we  have  added  eleven  students  for 
this  summer  to  implement  code  specified  by  staff  members. 
This  effort  should  help  to  stay  closer  to  the  schedule.   As 
the  charts  show,  the  project  is  about  one  month  behind  on  the 
schedule  originally  prepared  one  year  ago. 

In  the  following  charts  the  schedule  for  activities  is 
grouped  by  project  tasks.   These  are  activities  of  the  critical 
path  network  shown  in  earlier  quarterly  reports.   So,  progress 
can  be  visualized  according  to  the  original  schedule. 

Keys  to  the  schedule  charts  listed  below.   This  is  an 
adaptation  of  the  DOE  internal  method  of  standard  symbology 
(U.S.  DOE,  1977) . 

1.    The  time  line  indicating  date  of  the  chart  is  a 
vertical  dotted  line. 
An  open  bar  indicates  scheduled  work. 

A  shaded  bar  indicates  completed  work.   Shading  beyond 
the  time  line  indicates  progress  ahead  of  schedule  and 
shading  before  the  time  line  indicates  the  degree  of 
progress. 


2. 

3. 
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5. 


4.   A  triangle, A,  shows  the  original  scheduled  completion 
date.   If  shaded  it  means  completed  on  schedule.   If 
not  shaded  it  is  the  anticipated  schedule  for 
completion. 

A  diamond,  <},  indicates  a  deviation  from  the  schedule 
for  completion.   If  shaded,  it  shows  the  completion 
date  which  was  not  on  schedule.   If  not  shaded,  it 
shows  the  anticipated  completion  date. 
Activities  beyond  the  chart  are  shown  by  their 
scheduled  dates  of  start  and  ending. 
"TBD"  is  a  date  to  be  determined. 
The  critical  path  scheduling  program  used  is  the  IBM  pro- 
gram product  called  PROJACS.   The  dates  shown  on  this  schedule 
are  "late  start"  dates.   That  means  activities  must  be  started 
before  or  on  the  times  shown  in  order  to  meet  the  schedule. 


6. 


7. 
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III.   DETAILED  DESCRIPTION  OF  TECHNICAL  PROGRESS 


TASK  1;   DEVELOPMENT  OF  A  PROTOTYPE  SIMULATOR  AND  SIMULATION  OF 
SPECIFIC  FOSSIL  ENERGY  PROCESSES 


A  prototype  process  simulator  (PLEXSYS  II)  was  developed 
during  the  first  year  of  the  project  to  test  new  approaches  to 
process  simulation  needed  to  model  fossil  energy  processes. 
Three  specific  fossil  fuel  conversion  processes,  the  Institute 
of  Gas  Technology  (IGT)  HYGAS  Process,  the  Exxon  Donor  Solvent 
(EDS)  Process,  and  the  Conoco  Coal  Development  Company  CO2 
Acceptor  Process,  were  chosen  for  conducting  simulation  studies 
with  the  prototype  process  simulator.   The  purpose  of  these 
studies  is  to  demonstrate  the  ability  to  simulate  fossil  energy 
processes  of  interest  to  the  Department  of  Energy.   The  study 
of  the  IGT  HYGAS  Process  and  CO2  Acceptor  Process  was  com- 
pleted during  this  year.   Progress  on  the  simulation  of  the 
Exxon  Donor  Solvent  coal  liquefaction  process  has  been  delayed 
by  the  lack  of  published  literature  on  the  process  and  lack 
of  access  to  data  collected  by  Exxon.   An  agreement  has  been 
worked  out  with  Exxon  to  obtain  some  of  the  proprietary  data  on 
the  process  and  we  are  in  the  process  of  obtaining  reports  from 
Exxon. 
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The  following  sections  under  Task  1  describe  the  simulation 
studies  carried  out  on  the  HYGAS  Process  and  the  CO2  Acceptor 
Process  uisng  the  prototype  simulator,  PLEXSYS  II. 

1.1   THE  HYGAS  PROCESS 

The  HYGAS  coal  gasification  process  developed  by  the 
Institute  of  Gas  Technology  (IGT)  was  the  first  of  the  three 
processes  designated  by  ERDA  for  study.   An  80  ton  per  day 
pilot  plant  of  the  process  has  been  constructed  and  operated 
by  IGT  to  generate  design  information.   This  study  was  done  as 
part  of  a  M.S.  thesis  (White,  1977)  and  its  objective  was  to 
demonstrate  the  feasibility  of  computer  simulation  of  the  coal 
conversion  processes  by  comparing  the  simulation  results  with 
pilot  plant  data.   A  detailed  report  documenting  this  study  was 
included  in  the  Fifth  Quarterly  Progress  Report.   The  results 
are  summarized  in  this  section. 


1.1.1 


HYGAS  PROCESS  WITH  STEAM-OXYGEN  GASIFICATION 


Figure  1.1  is  a  schematic  drawing  of  the  process  except  for 
the  coal  handling  and  pretreatment.   Coal  is  ground  to  a  -10 
mesh  size  range.   For  agglomerating  coals,  oxidative 
pretreatment  is  required.   For  non-agglomerating  coals,  such  as 
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lignite,  no  pretreatment  is  required.   The  coal  is  slurried 
with  a  light  oil  (toluene  in  the  pilot  plant)  to  a  solids 
content  of  roughly  one-third  and  is  pumped  into  the 
hydrogasif ier  at  about  70  atmospheres. 

The  gasifier  reactor  tower  is  shown  in  Figure  1.2.   The 
slurry  enters  the  top  fluidized  bed,  where  the  oil  vaporizes 
and  exits  with  the  reactor  gases  to  be  recovered  and  recycled. 
At  approximately  600°?  the  dried  coal  flows  by  gravity 
through  a  dipleg  to  reach  a  lift  pipe  to  be  heated  and  devola- 
tilized  by  hot  gases  (at  about  ITOOOp) .   Also  in  this  sec- 
tion, called  the  Low-Temperature  Reactor  (LTR) ,  hydrogen  in  the 
gas  reacts  with  coal  to  form  methane. 

From  a  solids  disengaging  section  the  coal  enters  the 
second  stage  hydrogasif ication  section,  known  as  the  High- 
Temperature  Reactor  (HTR) .   The  HTR  is  a  dense-phase  fluidized 
bed  to  be  operated  at  1700-18000?.   The  principal  reactions 
are: 


C  +  2Ho  = 


CH4 


C  +  H2  =  CO  +  H2 
CO  +  H2O  =  CO2  +  H2 


(1.1) 
(1.2) 
(1.3) 


//y/:^.'9y. 
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Figure  1.2   HYGAS  Gasifier  with  Steam-Oxygen  Gasification 
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The  coal  char  finally  reaches  the  bottom  bed,  the  Steam- 
Oxygen  Gasifier  (SOG) ,  which  is  to  operate  near  ISOOOp.   In 
addition  to  the  above  reactions,  the  combustion  of  char  by  the 
oxygen  feed  also  occurs  in  the  SOG.   A  hydrogen-rich  gas  is 
produced,  and  the  remaining  char  and  ash  is  discharged  through 
a  lock  hopper. 

The  gas  exiting  the  gasifier  is  water-quenched  to  remove 
the  toluene,  other  oils  and  tars,  and  coal  dust.   The  toluene 
is  recovered  in  a  settling  tank,  and  then  recycled  to  the 
slurry  mixer.   The  aqueous  mixture  and  the  collected  dust  are 
discarded. 

For  the  removal  of  carbon  dioxide  and  hydrogen  sulfide, 
the  quenched  gas  passes  through  a  diglycolamine  absorber.   A 
caustic-water  wash  removes  the  last  trace  of  sulfur-containing 
compounds. 

A  methanation  section  is  the  final  process  unit  to  upgrade 
the  heating  value  of  the  gas  to  pipeline-quality  standards  by 
the  highly  exothermic  reaction: 


CO  +  3H2  ;*  CH4  +  H2O    AH298K  =  -88,700  Btu/lb-mole      (1.4) 


Recycle  of  cooled  product  gas  is  used  to  control  the 

temperature  in  the  reactor.   With  the  steam-oxygen  pilot  plant 

the  H2/C0  ratio  of  the  methanation  feed  was  found  to  be  close 
to  3/1  without  a  CO  shift  reactor. 
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1.1.2 


PILOT  PLANT  DATA 


The  particular  pilot  plant  run  chosen  for  matching  with  a 
simulator  study  was  Gasification  Test  37.   In  this  run  con- 
tinuous operation  of  the  entire  plant  was  achieved  for  362 
hours  beginning  on  June  23,  1975.   During  this  test  757  tons 
of  dried  lignite  were  fed  to  the  gasifier,  for  an  average  feed 
rate  of  about  2  tons  per  hour.   Data  were  taken  during  five 
separate  recording  periods  of  the  run. 

The  third  recording  period  of  Test  37,  from  8:00  p.m.  to 
11:59  p.m.  on  June  29,  1975,  was  selected  for  the  most  detailed 
examination.   This  period  appears  to  give  a  more  reasonable 
material  balance  and  also  more  complete  information.   Informa- 
tion was  taken  from  the  IGT  report  (HYGAS,  Interim  Report  No. 
2,    1975). 


1.1.3   HYGAS  SIMULATION 


The  HYGAS  process  flow  sheet,  as  in  Figure  1.3,  can  be 
visualized  also  as  a  computational  flow  sheet  shown  in  Figure 
1.4.   For  simulation,  computational  modules  are  put  into  the 
place  of  process  units  and  stream  information  is  conveyed  to 
the  modules  (or  blocks,  as  sometimes  called)  with  much  the  same 
flow  as  in  the  process  flow  sheet.   The  PLEXSYS  II  prototype 
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simulator  was  used  to  perform  the  calculations.   The  flowsheet 
was  divided  into  three  sections;  the  Gasification  section,  the 
Quench  and  Gas  Purification  Sections  and  the  Methanation  Sec- 
tion.  These  sections  were  described  in  detail  in  the  Fifth 
Quarterly  Progress  Report. 

1.1-4.    RESULTS  AND  COMPARISON  WITH  PILOT  PLANT 

MATERIAL  BALANCE  COMPARISONS 

Results  showed  that  the  gasifier  model  predicts  more  gas 
to  the  quench  unit  than  in  the  pilot  unit.   All  other  streams 
matched  quite  closely.   Some  selected  streams  are  compared  in 
Table  1.1;  the  model  shows  302  moles/hour  of  quenched  gas  but 
the  pilot  plant  records  217  moles/hour. 

This  is  partially  explained  by  the  closure  of  the  carbon 
balance  for  this  particular  recording  period.   As  the  pilot 
plant  material  balance  shows  (Fifth  Quarterly  Progress  Report), 
closure  between  inputs  and  outputs  is  +3-4%  for  all  atomic 
species  (except  sulphur) .   This  is  an  expected  overall  accuracy 
for  a  pilot  plant.   However,  the  carbon  balance  has  a  -12.6% 
error  when  considering  only  the  carbon  in  coal,  as  in  Table  1.2. 


3HR9^^B^F 
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TABLE  1.  1 

Comparison  of  Pilot  Plant  and  Simulation 

for  Selected  Gas  Streams 

(Moles/Hour) 


Quench  Gas 
Product 


H 


2 

CO  2 

^2«6 

N2 

H2S 

CH4 

CO 

Total 

P.P. 

72.5 
71.6 

.7 
13.6 

.5 

37.8 

20.3 

217.0 


Sim. 

111.1 

93.0 

0 

15.3 

1.0 

52.3 

29.3 

302.0 


Purification 
Feed 

P.P. 

Sim. 

41.1 

46.7 

41.6 

39.1 

0.4 

0 

7.9 

6.6 

0.3 

0.4 

21.9 

22.0 

11.8 

12.3 

Methanation 
Feed 


126.0    127.1 


P.P. 
39.2 

0 

1.2 

8.2 

0 
21.1 
11.3 
81.0 


Sim. 
46.7 

0 

0 

6.5 

0 
22.0 
12.3 
87.5 


Methanation 
Recycle 


H. 


CH4 
CO 

Total 


P.P. 
25.4 

0 
35.0 
145.6 

0 
219.0 


Sim. 
39.2 

0 
25.8 

137.3 

0 
202.3 


Product 

Gas 

P.P. 

Sim. 

6.4 

9.8 

0 

0 

8.8 

6.5 

36.8 

34.  3 

0 

0 

52.0 

50.6 

TABLE  1 . 2 

Carbon  Balance  Comparison 
Moles/Hour  (Excluding  Light  Oil) 
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In 


Coal 


Pilot  Plant 


266.3 


Simulation 


266.3 


Out 


Dust 
Char 

Product  Gas 
CO^ 


C2H4 


CH 


CO 


13.7 
57.6 

71.5 

1.5 

37.8 

20.3 


14.8 
57.6 

93.0 

52.3 
29.3 


Dissolved  in  Water 
Toluene  Vent  Gases 
Stripped  Vent  Gas 

Net  Make  of  Light  Oil 
Total  out 
%  Error 


2.7 

14.8 

1.8 

221.7 

14.7 
236.4 
-12.6% 


19.3 


266.3 

266.3 
0 
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The  simulation  was  made  with  each  block,  and  therefore  the 
entire  model,  to  be  in  material  balance.   The  simulation  was 
made  to  match  all  pilot  plant  input  flows  and  to  match  the  char 
flow  out.   Therefore,  when  comparing  gas  flows  out,  the  simu- 
lation results  show  a  higher  gas  rate  out  than  the  pilot  plant 
data. 

Additionally,  this  run  and  all  others  showed  some  net  make 
of  light  oils  which  are  used  to  slurry  the  coal  into  the  gasi- 
fier.   The  gasifier  model  in  this  simulation  did  not  account 
for  a  make  of  oil;  only  the  reactions  previously  listed  are  the 
routes  for  carbon  to  react.   So  this  further  accounts  for  a 
lower  amount  of  gas  in  the  pilot  plant  data  as  some  material 
goes  to  the  light  oils. 

A  simple  split  routine  was  used  to  remove  water  and  toluene 
from  the  gasifier  outlet  to  simulate  the  quench  operation. 
This  is  a  substitute  for  a  three-phase  flash  routine  which  is 
not  available  in  the  PLEXSYS  system.   Some  results  made  on 
FLOWTRAN  for  comparison  showed  a  substantial  solubility  of 

^^2  ^^^   ^^4  ii^  the  toluene  condensed.   The  pilot  plant  data 
showed  that  about  10%  of  the  gas  in  the  quench  is  dissolved  in 
condensed  toluene  and  a  smaller  amount  in  condensed  water.   A 
split  block  was  used  in  the  simulation  to  model  this  also.   In 
the  plant  design  a  recovery  unit  will  be  required  to  obtain  the 
dissolved  gases. 
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Before  going  on  to  the  purification  unit  some  of  the 
quenched  gas  is  flared.   In  the  simulation,  enough  gas  was 
flared  so  that  the  same  total  flow  was  put  into  the  acid  gas 
purification.   In  comparing  molar  flow  rates  here,  the  composi- 
tions are  quite  close  between  pilot  unit  and  simulation. 

For  simulations  the  CSPLIT  block  was  entirely  sufficient 
for  modeling  the  acid  gas  removal  section,  which  has  the  simple 
purpose  of  removing  CO^  and  sulfur-containing  compounds.   In 
fact,  there  was  some  loss  of  product  gas  into  the  absorbent 
fluid,  but  a  quite  sophisticated  absorber  model  would  be  needed 
to  properly  account  for  this. 

Modeling  of  the  methanation  section  of  the  pilot  plant 
proved  to  be  effective.   Agreement  with  the  pilot  plant  was 
good.   The  model's  results  compare  well  with  a  FLOWTRAN  model 
(not  shown  here) .   The  recycle  calculations  are  not  difficult 
in  the  model;  convergence  was  obtained  always  in  three  to  four 
iterations. 

As  seen  in  Table  1.1  the  simulator  had  a  higher  amount  of 
hydrogen  in  the  methanation  feed  than  the  pilot  unit.   Also, 
errors  in  the  pilot  plant  analysis  showed  slightly  more  methane 
in  the  product  than  methane  and  carbon  monoxide  in  the  feed. 
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PROCESS  TEMPERATURES 

A  comparison  of  process  temperatures  is  shown  in  Table 
1.3.   The  gasifier  temperatures  agreed  quite  well.   The  LTR  and 
HT^  reactor  sections,  operating  at  833  and  1320Of  respec- 
tively, were  modeled  by  one  lumped  reactor  which  was  calculated 
to  be  1190OF. 

In  the  methanator  reactors  a  higher  temperature  rise  was 
found  by  the  model.   This  was  also  confirmed  in  a  FLOWTRAN  sim- 
ulation.  The  most  probable  reason  is  that  the  model  assumed  no 
heat  loss  in  the  reactors,  whereas  the  pilot  unit  reactors  do 
have  some  losses.   Inlet  temperature  to  the  second  reactor  is 
higher  because  of  the  resultant  temperature  from  mixing  recycle 
with  the  first  reactor  effluent  flow. 


SENSITIVITY  OF  METHANATION  SECTION  TO  ASSUMED  SPLIT  FRACTIONS 

Any  errors  in  the  split  fractions  have  large  effects  on  the 
flowrates  and  reaction  temperatures. 

The  effects  of  variations  in  the  split  fractions  are  as 
much  as  might  be  expected.   Increasing  the  fraction  of  the  feed 
sent  to  the  first  reactor  increases  the  amount  of  CO  to  be 
reacted,  and  increases  the  outlet  temperature.   Increasing  the 
product  split  fraction  decreases  the  recycle  ratio  and  thus  the 
amount  of  inert  bulk  available  in  the  recycle  stream,  so  the 
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TABLE  1. 3 


Comparison  of  Pilot  Plant  and  Simulation  for 
Process  Temperature 
("F) 


Gasif ier : 

Slurry  Drier 

LTR 

HTR 

Steam-Oxygen  Reactor 


Pilot  Plant 

S 

imulation 

549 

540 

833 

1190 

1320 

) 

1509 

1509* 

Methanation: 

Reactor  #1  Inlet 

Reactor  #1  Outlet 

Reactor  #2  Inlet 

Reactor  #2  Outlet 


545 
779 
537 
758 


545* 
825 
654 
835 


*Note:    These  temperatures  were  used  as  input  data  to  the 
simulation,  others  were  calculated  to  satisfy  an 
energy  balance. 


/,. 
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reactor  temperatures  increase.  When  the  splitter  is  adjusted 
to  send  more  recycle  to  the  first  reactor  its  outlet  tempera- 
ture decreases  and  the  second  reactor's  temperature  increases. 

Sizing  calculations  were  done  for  the  acid  gas  absorber  and 
regenerator  columns  and  the  methanation  reactor.   This  work  was 
reported  in  the  Fifth  Quarterly  Progress  Report  and  is  not 
reported  here. 


1.2   THE  CO2  ACCEPTOR  PROCESS 


Acceptor  Process  is  a  fluidized  bed  system  to 
produce  high  3TU  gas  from  lignite  or  subbituminous  coal.   The 
process  has  been  developed  by  the  Conoco  Coal  Development 
Company.   A  40  ton  per  day  pilot  plant  has  been  operated  by 
Conoco  at  Rapid  City,  South  Dakota  since  1972  to  generate 
design  information.   The  objective  of  this  study  was  to  demon- 
strate the  ability  of  a  modular  computer  simulation  (i.e.  a 
simulation  comprised  of  several  computational  subroutines  or 
blocks  which  are  executed  sequentially)  to  handle  a  coal 
conversion  process  by  comparing  and  matching  the  simulation 
results  with  pilot  plant  data. 

A  schematic  diagram  of  the  process  is  shown  in  Figure  1.5. 
Raw  lignite  from  the  mine  is  trucked  to  the  lignite  sotrage  and 
handling  section,  a  system  of  conveyors  which  transport  coal 
among  storage  areas.   The  lignite  is  sent  to  the  pretreatment 
section  where  it  is  crushed,  dried,  and  preheated.   It  is  fed 


4J 
U 

3 

0 

u 
a, 


c 

0 

•H 

n 

0 
•H 
y-l 

■H 

3 


(J 


C  C 

0  0 

•H  -H 

C    C    M 

+j  x: 

0)  0) 

S  Q 


c 

•H 


H      > 


to 

•H 

0 


46 


u 

TJ 

(D 

(T3 

•H 

Q) 

M-l 

s: 

■H 

U 

CO 

0 

T3 

> 

O 

o 

n 

tu 

Q) 

4-1 

C 

•H 

•H 

e 

u 

0 

1— 1 

r-l 

03 

0 

U 

Q 

>i 

U 

V4 

3 

(U 

14-1 

> 

M 

0 

3 

0 

CO 

cu 

« 

4J 

\ 

to 

u 

T3 

(U 

■H 

■r-^(-H     1 

0) 

0  y 

\pi 

^/ 

c 
■J) 


u 


•H 


CJ     rT3CO-Hl44.HUfT34J-HOC 


W 


e 

'  tu 


CU 
■P 
•H 

6 
0 

0 
Q 


(T3 


40) 

4J 

c 

C7> 


c 


4J 


0) 
en 
ii3    CJi 


CT  -O 

C 

tu    iT3 

4J   ~ 

•-<    rr. 
C  ^ 

??3 


(U 

4J 
■H 


to 

CO 

<u 
u 
o 
(J 

0. 


vU 

u 

CJ 

< 

I 

o 

u 

cu 

x: 

4J 
4-1 

o 

E 
(t3 
U 
Cn 
tT3 

•H 

Q 

U 
•H 
4J 

fO 

(U 

x: 
u 


in 


tu 

u 

3 

cn 

•H 


47 


to  the  gasifier  where  it  reacts  with  steam  in  the  presence  of 
calcined  dolomite.   Dolomite  absorbs  CO2  and  H^S  in  the 
gasifier  and  produces  a  hydrogen  rich  product  gas,  low  in 
H2S.   Spent  dolomite  is  regenerated  to  drive  off  CO-  by 
burning  char  in  the  regenerator.   Since  H2S  is  not  recovered 
during  regeneration,  some  spent  dolomite  is  removed  for  sulfur 
recovery.   Hence,  make-up  dolomite  is  added  from  the  dolomite 
preparation  and  handling  section.   Waste  solids  (principally 
ash)  are  removed  from  the  gasifier  and  regenerator  overhead 
streams,  combined  with  reject  dolomite,  and  sent  to  the  waste 
solids  treatment  section.   Here,  spent  dolomite  is  reacted  with 
CO2  to  release  H2S  which  is  sent  to  the  sulfur  recovery 
section.   Product  gas  from  the  gasifier  is  purified  to  remove 
CO2  and  H2S  and  sent  to  the  methanation  and  dehydration 
sections.   Since  CO2  is  absorbed  by  dolomite  in  the  gasifier 
and  Hj  is  produced,  a  process  for  shift  conversion  is  not 
necessary. 

In  this  work,  the  lignite  pretreatment  and  gasification 
sections  were  modelled.   The  work  was  carried  out  in  two 
pacts.   The  coal  pretreatment  section  of  the  pilot  plant  was 
simulated  at  the  University  of  Pennsylvania  under  a  subcontract 
and  the  gasification  section  of  the  pilot  plant  was  simulated 
at  M.I.T.   The  gas  purification  section  and  the  methanation 
section  were  not  simulated  because  the  Conoco  Coal  Development 
Company  had  not  published  pilot  plant  data  for  these  sections. 
It  was  also  felt  that  simulation  of  these  sections  would 
duplicate  the  work  already  performed  in  the  HYGAS  simulation. 


48 


1.2.1   THE  PRETREATMENT  SECTION 


In  this  work,  the  lignite  pretreatment  section  designed  by 
the  Bureau  of  Mines  (1976)  was  studied  rather  than  the  Rapid 
City  pretreatment  section,  about  which  information  has  not 
been  published. 

The  pretreatment  section  of  the  process  includes  grinding, 
drying  and  preheating.   The  flowsheet  is  shown  in  Figure  1.6. 
Lignite  from  storage  is  fed  to  receiving  hoppers  and  from 
there  to  the  primary  crusher  where  it  is  reduced  to  less  than 
one  inch.   Crushed  lignite  is  transported  to  hot  gas  swept 
hammer  mills  where  it  is  ground  to  less  than  one  eighth  inch. 
Hot  flue  gas  from  the  furnace  at  600^F  reduces  the  moisture 
content  of  lignite  from  40  to  20  percent.   After  gases  are 
removed  in  cyclones,  some  lignite  is  sent  to  furnaces  for 
combustion  and  the  remainder  proceeds  to  flash  dryers,  where 
it  is  contacted  with  hot  flue  gas  and  its  moisture  reduced  to 
5  percent.   Finally,  at  2Q0Of,  the  lignite  is  sent  to  fluid- 
ized  bed  preheaters  where  it  is  heated  to  500<^F  and  the 
remaining  moisture  removed.   The  pretreated  lignite  is  then 
transported  to  the  gasification  process.   The  simulation  block 
diagram  for  the  pretreatment  section  is  shown  in  Figure  1.7. 
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Programs  for  the  crusher,  hot  gas  swept  hammer  mill, 
furnace,  cyclone  separator,  flash  dryer  and  fluidized  bed 
preheater/dryer  were  completed  and  tested  under  this  work. 
The  models  for  these  unit  operations  are  included  in  Section 
4.2.   The  M.S.  thesis  of  James  M.  Neville  (1978)  describes 
this  work  in  detail. 

Pilot  plant  data  for  COj  Acceptor  Process  Pretreatment 
were  not  available  to  verify  the  simulation  results.   To 
verify  various  models,  the  programs  were  compared  with  exper- 
imental data  available  from  other  sources.   The  furnace  model 
was  compared  with  IGT  results.   There  was  almost  no  disagree- 
ment between  IGT  data  and  the  computed  results.   Only  the 
temperatures  disagreed  because  IGT  ignored  ash  on  their  energy 
balance.   The  results  obtained  from  the  cyclone  model  were 
very  close  to  the  data  given  in  Lieth  and  Licht  (1972)  for 
monodispersed  particles.   The  experimental  data  of  Mcintosh 
(1976)  were  used  to  verify  the  flash  dryer  model.   The  solids 
residence  time  was  not  adjusted  to  match  the  experimental  out- 
let coal  moisture  content  and  the  computed  value  differs  by 
approximately  4  percent.   The  predicted  outlet  temperature  was 
approximately  ISQOc  higher  and  the  gas  flow  rate  was  some- 
what lower.   Both  differences  are  expected  since  drying  is  not 
completed.   Finally,  the  compositions  are  close  to  agreement. 
This  comparison  increases  confidence  in  the  predictions  of  the 
drying  model. 
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Unfortunately,  experimental  data  was  not  available  to 
permit  conclusions  concerning  crusher,  hot  gas  swept  hammer 
mill  and  fulidized  bed  perheater  models.   The  computed  results 
for  these  models  were  compared  with  results  of  the  Bureau  of 
Mines  design  study.   The  inlet  particle  size  distribution  for 
the  crusher  was  missing  and  therefore  the  models  validity 
could  not  be  confirmed.   In  the  case  of  hot  gas  swept  hammer 
mill,  good  agreement  was  not  obtained  with  results  of  the 
Bureau  of  Mines  designing  study,  probably  due  to  an  error  in 
their  calculations,  as  discussed  by  Neville  (1978). 

1.2.2   THE  GASIFICATION  SECTION 


1.2.2.1  Description  of  the  Pilot  Plant 

The  heart  of  the  process  is  the  gasif ier-regenerator  sys- 
tem in  Figure  1.8.   It  consists  of  two  fluidized  bed  reactors, 
a  gasifier  and  a  regenerator.   These  reactors  operate  in  the 
pressure  range  of  115  to  150  psig.   Operating  temperatures 
range  from  1490  to  ISSO^F  in  the  gasifier  and  1800  to 
1850'^F  in  the  regenerator. 

Since  the  beginning  of  the  pilot  plant  operation,  small 
modifications  in  the  flowsheet  have  been  made  from  time  to 
time.   The  broken  lines  in  Figure  1.8  represent  streams  which 
were  present  during  only  a  few  pilot  plant  runs.   These 
streams  may  be  easily  added  to  or  removed  from  the  simulation. 
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Figure  1.8  Process  Diagram  for  the  GAsification  Section 
of  the  CO2  Acceptor  Process 

(Figure  taken  from  "The  CO,  Acceptor  Process"  (Sudbury  et  al 
1977)  and  modified)       ^  1  •  , 
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Pretreated  coal  from  the  pretreatment  section  is  fed  to  the 
gasifier  at  the  bottom  of  a  fluidized  bed  of  char.   This  is 
done  so  that  both  hydro-devolatilization  and  gasification  could 
take  place  in  a  single  reactor.   S-team  is  fed  at  the  bottom  of 
the  gasifier.   After  a  rapid  hydro-devolatization,  fixed  carbon 
in  the  char  is  gasified  by  the  endothermic  reactions: 


C  +  H20(g)   =   CO  +  H2 
2C  +  HjOCg)  +  H2   *   CH^  +  CO 


(1.5) 
(1.6) 


Carbon  dioxide  is  formed  by  the  water  gas  shift  reaction. 


CO  +  H 


20(g)   »  CO2  +  H2 


(1.7) 


The  heat  duty  required  to  maintain  the  desired  temperature 
is  supplied  by  the  sensible  heat  of  acceptor  and  by  the  exo- 
thermic carbonation  of  the  acceptor  as  it  "accepts"  CO2. 


CaO  +  CO. 


CaC03 


AH  ■  -76,200  Btu/lbmole  at  60°F   (1.8) 


The  acceptor,  which  can  be  limestone  or  dolomite,  showers 
through  the  gasifier  and  collects  in  the  gasifier  boot.   Steam 
flow  to  the  bottom  of  the  boot  is  adjusted  to  cleanly  strip  the 


.&i 
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char  from  the  acceptor.   The  remaining  steam  needed  for  gasifi' 
cation  of  fixed  carbon  enters  through  a  distributor  above  the 
boot.   The  product  gas  from  the  gasifier  is  fed  to  the  purifi- 
cation and  methanation  section. 

The  recarbonated  acceptor  is  conveyed  pneumatically  to  the 
bottom  of  the  regenerator.   Residual  char  from  the  gasifier  is 
also  conveyed  by  a  stream  of  regenerator  recycle  gas  to  the 
regenerator  where  it  is  burned  with  air  to  raise  the  tempera- 
ture of  the  fluidized  bed  acceptor  to  about  ISSO^f.   At  this 
temperature  the  acceptor  is  calcined  by  reversal  of  the  CO2 
acceptor  reaction. 


CaCO^   =  CaO  +  CO2 


(1.9) 


The  calcined  acceptor  is  returned  by  gravity  to  the  gasifier, 
thus  completing  the  acceptor  loop.  The  acceptor  inventory  is 
maintained  by  continual  addition  of  makeup  acceptor. 


1'2.2.2   Simulation  of  the  Gasification  Section 

Figure  1.9  shows  a  block  diagram  for  the  gasification 

section  of  the  CO^   Acceptor  Process.   This  block  diagram  has 
been  prepared  so  that  it  can  simulate  present  pilot  plant,  as 
well  as  previous  pilot  plant  arrangements.   Depending  on  the 
arrangement  to  be  simulated,  some  streams  can  be  set  to  zero. 
The  nine  different  blocks  required  for  the  simulation  are 
described  below. 
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1.  ADD  -  This  is  a  general  stream  mixer.   It  mixes  any 
number  of  streams  of  any  class  and  produces  one  output 
stream. 

2.  CONVG   -  This  stream  convergence  block  converges  any 
number  of  streams  of  any  class  simultaneously.   Convergence 
variables  are  temperature,  total  flow,  and  total  enthalpy 
flow  of  each  phase  in  the  stream  (i.e.,  gas,  acceptor,  or 
coal) .   The  method  used  is  direct  substitution. 

3.  CSP  -  The  CSP  block  is  a  model  of  an  idealized  separation 
process.   It  places  specified  fractions  of  specified  or 
'key'  components  from  an  inlet  stream  into  output  streams. 
The  temperature  and  pressure  for  all  streams  are  equal. 

The  inlet  and  outlet  streams  are  allowed  to  be  of  a 
different  type. 

4.  GASIF  -  This  block  models  the  gasifier  for  the  COj 
Acceptor  Process.   It  is  a  single  block  consisting  of  three 
sub-blocks  as  shown  in  Figure  1.10.   All  the  gases  fed  to 
the  gasifier  are  first  mixed  in  an  ADD  sub-block  and  then 
fed  to  the  reactor  block  GASR.   The  output  stream, 
containing  solids,  is  split  into  two  streams  of  char  and 
acceptor  respectively. 
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5.   GASR  -  This  is  the  block  called  by  GASIF  which  actually 
solves  for  all  the  outlet  stream  flows,  compositions,  and 
temperatures.   Given  all  inlet  stream  flows,  compositions, 
and  temperatures  it  requires  in  addition  the  following 
parameters: 

1)  The  percent  of  coal  nitrogen  converted  to  ammonia 

2)  The  outlet  char  compositions 

3)  The  ratio  (char  to  cyclone) /(char  to  regenerator) 

4)  The  heat  loss. 
The  reactions  used  are: 


Coal  +  HjO 
CaO  +  CO2 
CO  +  3H2 
CaO  +  HjS 
CO  +  HjO 


char  +  CO  +  CO2  +  H2  +  N2  +  NH3  +  H2S 
CaC03 

CH4  +  H2O 

CaS  +  H2O 

CO2  +  H2 


(1.10) 

(1.8) 

(1.11) 

(1.12) 
(1.7) 


Reaction  (1.10)  goes  to  completion.   The  extent  of  reaction 
(1.8)  is  fixed  by  the  activity  (conversion  to  CaC03)  of  the 
acceptor,  and  the  extent  of  reaction  (1.11)  is  fixed  by  speci- 
fying the  mole  fraction  of  methane  in  the  product  gas.   Reac- 
tions (1.12)  and  (1.7)  are  calculated  by  specifying  some  frac- 
tional approach  to  equilibrium.   Reactions  (1.11),  (1.12),  and 
(1.7)  are  solved  simultaneously  to  generate  the  overhead  gas 
composition. 
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6.  PSP  -  This  block  splits  a  stream  of  multiple  phases  into 
streams  with  specified  phases. 

7.  REGEN  -  This  block  models  the  regenerator  of  the  COj 
Acceptor  Process.  As  shown  in  Figure  1.11,  the  REGENERATOR 
can  be  visualized  as  consisting  of  four  sub-blocks.  First, 
streams  of  char  and  acceptor  are  mixed.  Then  solid  and  gas 
phases  are  separated  so  that  gas  stream  could  be  mixed  with 
other  gas  streams.  The  gas  stream  from  the  mixer  and  the 
solid  stream  are  then  fed  to  the  reactor  block  REGNR. 

8.  REGNR  -  This  block  is  called  by  REGEN  and  solves  for  all 
the  outlet  stream  flows,  compositions,  and  temperatures. 
Given  all  inlet  stream  flows,  compositions,  and  tempera- 
tures it  requires  in  addition  the  following  parameters: 

1)  The  outlet  ash  compositions 

2)  The  percent  char  to  the  overhead  cyclone 

3)  The  percent  acceptor  to  the  overhead  cyclone 

4)  The  heat  loss. 
The  reactions  used  are: 


Char  +  O2 

= 

Ash 

+ 

CO2 

CaC03 

= 

CaO 

+ 

CO2 

CaS  +  3CO2 

= 

CaO 

+ 

SO  2 

CaS  +  H20 

= 

CaO 

4- 

H2S 

CaS  +  CO2 

= 

CaO 

+ 

COS 

CO  +  H2O 

= 

CO2 

+ 

H2 

(1.13) 
(1.9) 

(1.14) 
(1.15) 

(1.16) 
(1.7) 
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Reactions  (1.13)  and  (1.9)  go  to  completion.   Reactions  (1.14), 
(1.15),  (1.16),  and  (1.7)  are  calculated  by  specifying  some 
fractional  approach  to  equilibrium.   The  last  four  reactions 
here  are  solved  simultaneously  to  generate  the  outlet  gas 
composition. 

9.   SPLIT  -  This  is  a  simple  stream  split  block  which  will 
split  a  single  inlet  stream  into  any  number  of  outlet  streams 
given  a  list  of  split  fractions. 


1.2.2.3   Pilot  Plant  Data 

Since  the  beginning  of  the  pilot  plant  work  in  1972  Conoco 
has  made  over  70  runs  of  the  process.   Only  four,  however,  were 
reported  in  their  entirety.   Significant  data  are  shown  in 
Table  1.4.   Note  that  most  of  the  reported  runs  used  lignite 
as  the  feed  coal  and  limestone  as  the  acceptor. 

It  should  also  be  noted  that  the  flowrates  of  acceptor  and 
fuel  char  circulating  through  the  system  are  never  measured 
directly.   The  acceptor  flow  is  calculated  by  an  energy  bal- 
ance.  The  fuel  char  flow  is  calculated  by  forcing  the  carbon 
balance  around  the  regenerator. 

Run  26  was  chosen  as  the  base  case  since  it  typifies  most 
of  the  runs.   Atom  balances  for  both  reactors  for  this  run  were 
particularly  good.   The  pilot  plant  data  for  this  run  were  used 


TABLE  1.4 
PILOT  PLANT  DATA 
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RUN 


26 


28B 


38C* 


40B 


Date 


5/75 


8/75 


7/76 


6/77 


Coal,  type 

Lignite 

Lignite 

Subbit. 

Lignite 

flow(lbs/hr) 

2  450 

2  450 

2  530 

2  370 

Acceptor,  type 

Dolomite 

Limestone 

Limestone 

Limestone 

flow(lbs/hr) 

8  795 

12  767 

10  961 

6  653 

Fuel  char(lbs/hr)      623 


Air  to  gasifier 
(Ibs/hr) 


571 


692 


466 


570 


840 


Gasifier  heat  loss 
(MBtu/nr) 


243 


242 


247 


241 


Regen.  heat  loss 
(MBtu/hr) 


587 


587 


587 


590 


Calculated  by  Conoco  from  a  heat  balance. 
Calculated  by  Conoco  from  a  carbon  balance. 
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to  calculate  the  fractional  approaches  to  equilibrium  required 

for  the  various  reactions  in  the  gasifier  and  regenerator 

models.   These  same  values  were  then  used  in  simulations  of  all 
the  other  runs. 


1.2.2.4   CO2  Acceptor  Simulation 

From  the  simulation  block  diagram  it  is  seen  that  there  are 
three  recycle  streams  in  the  system,  namely  the  overhead  gas 
recycles  on  each  reactor  as  well  as  the  acceptor  recycle  that 
ties  the  two  reactors  together.   Given  initial  guesses  for  the 
recycle  streams  the  calculations  start  with  the  gasification 
section  and  proceed  to  the  regenerator.   When  the  last  unit  in 
the  calculation  sequence  is  completed,  the  stream  convergence 
block  CONVG  checks  all  three  recycles  for  convergence.   If 
these  are  not  all  converged,  then  another  iteration  of  calcu- 
lations is  started.   Such  a  calculation  sequence  is  shown  in 
Table  1.5.   The  method  attained  convergence  rapidly,  usually  in 
about  three  or  four  iterations. 

The  basic  strategy  was  to  match  the  base  case  pilot  plant 
data  and  then  use  the  same  parameters  for  all  the  other  runs. 
It  was  found  that  this  matching  could  be  accomplished  by  manip- 
ulating the  acceptor  flowrate  and  heat  loss  data.   That  is,  the 
acceptor  flowrate  used  was  some  factor,  alpha,  times  the  re- 
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TABLE  1.5 


ACCEPTOR  SIMULATION  CALCULATION  SEQUENCE 


Block  Name 


Computer  Model 


CSP2 

ADD? 

ADD6 

GAS  IF 

PSP2 

SPL4 

SPLl 

ADD  2 

ADDl 

ADD3 

ADD  4 

SPL3 

ADD5 

REG  EN 

SPL2 

PSPl 

CSPl 

CONl 


Component  split 

Add 

Add 

Gasif ier 

Phase  split 

Split 

Split 

Add 

Add 

Add 

Add 

Split 

Add 

Regenerator 

Split 

Phase  split 

Component  split 

Convergence 
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ported  flowrate.   Similarly  the  heat  losses  used  were  a  factor, 
beta,  times  the  reported  heat  losses.   A  match  of  the  base  case 
data  was  obtained  with  a  =1.45  and  6  =0.5.   This  is  shown  in 
Figure  1.12  which  dipicts  the  sensitivity  of  reactor  tempera- 
tures to  acceptor  flowrate  and  heat  loss. 

Following  this,  the  same  values  of  alpha  and  beta  were  used 
in  all  the  other  runs.   Table  1.6  shows  a  comparison  between 
pilot  plant  and  simulated  temperatures.   Table  1.7  shows  a  com- 
parison between  reported  and  simulated  flowrates.   The  agree- 
ment here  is  fairly  good.   Other  flows  match  quite  closely  as 
well. 

A  comparison  between  pilot  plant  and  simulated  compositions 
is  shown  in  Tables  1.8  and  1.9  for  the  gasifier  and  regenerator 
overheads.   Once  again  the  agreement  is  fairly  good. 

This  agreement  between  pilot  plant  and  simulated  results 
suggests  that  perhaps  the  acceptor  flowrate  measured  by  Conoco 
is  too  low  and  similarly  the  heat  losses  are  too  high.   In  any 
case  the  simulation  could  be  a  useful  tool  for  predicting 
trends  in  the  data  and  identifying  inconsistent  data. 


67 


|i! 


Ari'i'PTDR  FLDWRATF:   Gf-NLiilTIVITY 

■H '<»•  -.^^  I 1 \ 1 h 


REGENERATOR 
TEMPERATURES 


"^  p>-  .S 


/5-i 


/3  =    .i- 


GASIFIER 
g  _  _2         TEMPERATURES 


?330'00 
0 


I I 


'BOO  i'OGO    '         i-c=00    '        jT-ICCJ^        i'GCO  lisCO  ^"^000 

ACCEPTCR  FLDWRATE.(^X  REPCHTF^D  VALUE) 


FIGURE    1.12 


68 


TABLE  1.6 
REACTOR  TEMPERATURES 


RUN 

26 

28B 
38C 

403 


PP 
1  086 

1  083 

1  097 

1  089 


GAS IF I ER 
(K) 

SIM 

1  072 

1  040 

1  077 


1  074 


%  Diff, 
-1.3 


-3.9 


-1.8 


-1.4 


REGENERATOR 
(K) 

PP         SIM 

1  278     1  295 


1  278 


1  278 


1  283 


1  274 


1  336 


1  326 


%  Diff 


1.3 


0.3 


4.5 


3.4 


TABLE  1.7 
FLOWRATES 


RUN 

26 

28B 
38C 
40B 


Gasifier  product  gas 
(gmol/hr) 

PP        SIM       %  Diff 

67  508     66  900 


71  618     71  593 


80  175     80  740 


79  158     77  160 


-0.90 


-0.03 


0.70 


-2,5 


Regenerator  flue  gas 
(gmol/hr) 


PP 


SIM 


%  Diff. 


115  579    119  186    3.1 


119  732    120  018     0.2' 


123  723    123  661    -O.OI-. 


108  820    111  491 


2.5 


TABLE  1.8 

GASIFIER  PRODUCT  GAS  COMPOSITIONS 
(mol.  fret. ) 
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26 


28B 


38C 


403 


Component 

PP 

SIM 

CH4 

.1375 

,1375 

H2 

.5880 

.6387 

CO 

.1547 

.1193 

CO  2 

.0908 

.0745 

N2 

.0291 

.0300 

1.000   1.000 


PP  SIM 

.1253  .1253 

.5801  .5840 

.1561  .1545 

.1119  .1098 

.0265  .0265 

1.000  1.000 


PP  SIM 

.0878  .0878 

.5342  .5391 

.1556  .1454 

.0870  .0927 

.1354  .1351 

1.000  1.000 


TABLE  1.9 
Regenerator  Five  Gas  Compositions 


PP  SIM 

.1135  .1135 

.4325  .4606 

.1646  .1^27 

.1041  .0925 

.1852  .1907 

1.000  1.000 


26 

283 

PP 

SIM 

PP 

SIM 

H2 

.0006 

.00058 

.0011 

.0014 

CO 

.0220 

.0227 

.0350 

.0383 

CO  2 

.2935 

.3136 

.2817 

.2730 

B2 

.6840 

.6632 

.682 

.6896 

1.000   1.0000 


38C 

403 

PP 

SIM 

PP 

SIM 

.0008 

.00077 

.0012 

.00014 

.0350 

.0343 

.0255 

.03271 

.2824 

.2828 

.2699 

.2-  )4 

.6818 

.6821 

.7034 

.6865 

1.000   1.0000 


1.0000  1.0000 


1.0000   1.0000 
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1.3  EXXON  DONOR  SOLVENT  (EDS)  PROCESS 

Because  of  the  lack  of  published  data  on  the  process  and 
the  lack  of  access  to  pilot  plant  data  collected  by  Exxon, 
progress  on  the  simulation  studies  has  been  seriously 
hampered.   A  legal  agreement  has  been  worked  out  with  Exxon 
to  obtain  some  of  the  proprietary  data  on  the  process  under  a 
secrecy  agreement  and  we  have  obtained  the  published  reports 
from  Exxon,  which  were  cleared  for  release  in  the  past  quarter 

During  the  past  some  preliminary  studies  were  done  to 
determine  whether  traditional  petroleum  correlations  can  be 
used  to  predict  physical  properties  of  coal  liquids.   (The 
results  are  reported  under  Task  5.) 

1.4  WORK  FORECAST 


Simulation  of  the  HYGAS  Process  and  the  CO2  Acceptor 
Process  with  the  prototype  process  simulator  (PLEXSYS  II)  has 
been  completed.   These  simulations  demonstrated  that  a  simu- 
lator like  PLEXSYS  II  can  successfully  simulate  fossil  energy 
processes  of  interest  to  the  Department  of  Energy.   Simulation 
of  the  Exxon  Donor  Solvent  Process  has  not  been  completed  due 
to  the  lack  of  published  literature  on  the  process  and  lack  of 
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access  to  data  collected  by  Exxon.   Now,  an  agreement  has  been 
worked  out  with  Exxon  to  obtain  some  of  the  proprietary  data  on 
the  process.   After  obtaining  this  proprietary  data,  simulation 
of  this  process  could  be  completed  with  the  PLEXSYS  II.   How- 
ever, it  has  been  decided  that  at  this  stage  of  the  project  it 
would  not  be  appropriate  to  do  simulation  with  the  prototype 
simulator.   The  EDS  process  will  be  the  first  benchmark  problem 
for  the  ASPEN  system  and  work  on  it  will  start  in  the  next 
quarter.   The  work  done  for  prototype  simulation  will  be 
utilized  for  the  benchmark  problem. 

No  further  work  is  scheduled  under  this  task  in  the  next 
quarter. 
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TASK  2:   DEVELOPMENT  OF  ASPEN  SYSTEM  STRUCTURE 


During  the  past  year  this  task  has  been  essentially  com- 
pleted.  The  functional  specifications  were  completed  and 
reviewed  in  the  fifth  and  sixth  quarters  of  the  project  and  the 
design  specifications  were  completed  and  reviewed  with  the 
Advisory  Committee  in  the  past  quarter.   A  Design  Report  con- 
taining all  of  the  detailed  specifications  is  being  prepared 
and  will  be  issued  as  an  appendix  to  this  Annual  Report  in  the 
next  month.   The  salient  features  of  the  design  are  reported 
here. 

2.1   DESIGN  CRITERIA 


A  survey  was  conducted  to  get  the  recommendations  on  the 
preliminary  design  criteria  for  ASPEN  from  the  members  of  the 
Project  Advisory  Committee.   The  Advisory  Committee  consists  of 
representatives  from  industry,  government,  and  universities  and 
was  formed  to  advise  on  the  development  of  ASPEN  and  to  ensure 
that  it  will  meet  the  needs  of  the  ultimate  users.   A  question- 
naire based  on  preliminary  design  criteria  was  sent  to  all 
members  of  the  Advisory  Committee. 

The  results  from  the  questionnaires  were  analyzed  and  a 
summary  of  the  results  was  sent  to  members  of  the  Users/Use 
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Interface  Subcommittee  of  the  Task  Force  on  System  Design.   A 
meeting  of  the  Users/Use  Interface  Subcommittee  was  held  on 
August  22  at  M. I.T.  and  the  results  of  the  questionnaires  were 
discussed  in  detail  to  obtain  specific  inputs  from  the  partici- 
pants.  The  impact  of  the  questionnaire  results  on  ASPEN  system 
design  was  analyzed.   The  results  of  the  survey  were  reported 
in  the  Fifth  Quarterly  Report. 

2.2   FUNCTIONAL  SPECIFICATIONS 


During  the  second  quarter  of  last  year,  the  functional 
specifications  for  ASPEN  were  prepared.   These  functional 
specifications  describe  the  requirements  of  the  ASPEN  Exec- 
utive, the  Computational  Architecture,  the  Unit  Operations 
Subsystem,  the  Physical  Property  Subsystem,  and  the  Cost 
Estimation  and  Economic  Evaluation  Subsystem.   These  were 
reviewed  by  the  System  Design  Task  Force  during  the  January 
meeting  of  the  ASPEN  Advisory  Committee  in  order  to  produce  a 
final  version.   The  final  version  was  issued,  as  an  appendix 
to  the  Sixth  Quarterly  Progress  Report,  as  a  separate  volume. 

Various  computational  techniques  were  considered  in  detail; 
it  is  concluded  that  the  time  frame  for  ASPEN  will  not  permit 
the  implementation  of  new  strategies  which  have  not  been  well 
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tested  and  that  the  basic  architecture  for  ASPEN  will  be 
sequential  modular.   However,  it  was  felt  that  the  design  of 
the  system  should  be  carried  out  in  such  a  way  as  to  permit  the 
system  to  be  extended  in  the  future  to  include  other  computa- 
tional algorithms  being  developed. 

A  subcontract  was  negotiated  with  SofTech,  a  software 
technology  company,  to  assist  in  the  design  and  implementation 
of  the  system. 

2.3   SYSTEM  DESIGN  SPECIFICATIONS 

Based  on  the  Functional  Specifications,  a  detailed  design 
of  the  system  was  carried  out  using  the  structured  design 
methodology.   The  design  was  an  iterative  process  with  frequent 
reviews.   The  results  are  reported  in  complete  detail  as  an 
appendix  to  this  annual  report.   Due  to  the  size  of  the  Appen- 
dix it  is  being  published  as  a  separate  volume.   The  salient 
features  are  summarized  here. 

2.3.1   INPUT  LANGUAGE 


The  ASPEN  input  language  is  designed  with  the  thought  in 
mind  that  the  typical  user  of  ASPEN  will  be  a  process  engineer 
familiar  with  chemical  engineering  calculations  around  a  flow- 
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sheet.   He  may  or  may  not  know  computer  programming  and/or 
computer  methods  for  process  flowsheet.   Hence,  the  input 
language  will  have  enough  structure  so  that  a  process  engineer 
can  easily  input  and  understand  the  problem.   The  input  lan- 
guage will  be  completely  free  format  and  the  user  will  be  able 
to  input  the  problem  quickly  and  with  a  minimum  of  excess 
typing. 

In  the  complete  version  of  ASPEN  the  input  language  will 
have  commands  to  direct  the  system  to  take  certain  actions  such 
as  execution,  file  management,  etc.   Underneath  this  level  the 
language  will  consist  of  keywords.   The  keyword  driven  input 
will  be  divided  into  many  hierarchies.   A  keyword  may  contain 
many  selected  lower  order  keywords. 

The  ASPEN  input  language  can  be  considered  to  be  made  up  of 
paragraphs,  sentences  and  words.   A  paragraph  is  one  command 
and  may  consist  of  one  or  more  sentences.   Titles  of  paragraphs 
and  sentences  appear  first  within  them.   Tlie  titles  of  para- 
graphs are  primary  keywords  and  those  of  sentences  are  sec- 
ondary keywords.   These  keywords  are  used  to  indicate  the 
category  of  data  appearing  in  a  paragraph/sentence.   Hence, 
these  keywords  do  not  have  a  value  as  such.   Tertiary  keywords 
are  used  to  enter  data  and  their  values  are  the  data  items. 

The  ASPEN  input  language  is  free  format  and  the  user  has 
the  option  of  entering  data  positionally  or  using  keywords. 
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In  both  the  cases,  he  has  to  enter  all  primary  and  secondary 
keywords  which  are  required  for  entering  his  data.   However,  in 
the  positional  form,  he  does  not  enter  tertiary  keywords  and 
enters  data  items  only.   In  this  case,  data  items  are  assumed 
to  be  in  a  predetermined  order. 

Wherever  possible,  default  values  will  be  provided  for 
missing  data.   Data  will  be  checked  for  upper  and  lower 
bounds.   An  echo  of  the  input  will  be  provided.   It  will  show 
all  the  necessary  keywords  and  all  the  values  supplied  as 
default  values.   This  echo  of  the  input  can  be  saved  and  used 
as  input  to  another  simulation  run  of  the  same  process. 

Input  will  be  table-driven  with  tables  containing  keywords, 
defaults  and  data  types.   This  will  make  future  extension  to 
the  system  easy  to  implement. 

2.3.1.2   ASPEN  Commands 


ASPEN  commands  are  used  to  direct  the  system  to  take 
certain  actions  such  as  processing  of  input,  computing,  report 
writing  etc.   An  ASPEN  command  must  start  in  column  1.   The 
structures  of  ASPEN  commands  in  the  basic  and  complete  systems 
will  be  quite  different  and  hence  these  two  systems  are 
discussed  separately. 
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Basic  System 

The  basic  system  is  basically  a  batch  system  and  hence  does 
not  have  commands.   However,  there  are  few  keywords  which 
convey  the  meaning  similar  to  the  one  conveyed  by  commands  in 
the  complete  system.   The  keywords  used  for  this  purpose  are: 

1.  INPUT 

2.  EDIT 

3.  END  DATA 

4.  SIMULATE 

5 .  REPORT 

Out  of  these  five  keywords  a  maximum  of  two  keywords  can  be 
used  in  one  job  step.   These  keywords  are  explained  in  detail 
below. 

INPUT  asks  ASPEN  to  initialize  the  system  and  tells  that 
input  data  follows.   The  input  processor  reads  the  input, 
analyzes  it,  creates  the  data  structures,  and  generates  the 
main  program  and  other  FORTRAN  source  programs.   EDIT  is 
similar  to  INPUT  except  that  the  system  is  initialized  using 
results  of  a  previous  run  when  EDIT  keyword  is  used.   End  of 
data  for  INPUT  and  EDIT  keyword  is  used. 

END  DATA  asks  the  system  to  process  the  input,  create  the 
data  structures,  generate  the  main  program,  calculate  the 
sequence,  and  compile  the  source  FORTRAN.   If  SIMULATE  follows 
the  INPUT  or  EDIT  data,  it  asks  the  system  to  do  all  the  above 
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mentioned  things,  computations,  and  report  writing.   However, 
if  SIMULATE  appears  alone,  the  user  is  starting  from  already 
created  data  structures  and  compiled  programs  and  wants  the 
system  to  do  computations  and  report  writing.   REPORT  asks  the 
system  to  do  everything  which  SIMULATE  does  except  computations. 


Complete  System 

In  the  complete  ASPEN  system  commands  will  be  used  to 
direct  the  system  to  take  various  actions.   The  complete  system 
will  be  an  interactive  system  which  could  easily  be  run  in  the 
batch  also.   The  interaction  provided  in  the  system  will  be  a 
limited  interaction,  that  is,  there  will  be  no  interaction 
during  the  execution  of  a  command,  however,  after  execution  of 
the  command  the  control  will  be  returned  to  the  ASPEN  execu- 
tive.  Therefore,  the  user  will  be  able  to  give  many  commands 
one  after  another  without  going  through  the  load  and  link 
step.   In  the  description  of  ASPEN  commands  in  this  section, 
it  has  been  assumed  that  the  operating  system  is  advanced 
enough  (like  CMS)  to  permit  the  described  actions.   If  the 
operating  system  is  not  an  advanced  one,  the  complete  system, 
in  principle,  will  be  similar  to  the  basic  system. 
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The  complete  ASPEN  system  will  have  the  following  commands 

1 .  INPUT 

2.  EDIT 

3 .  EXECUTE 

4.  CONTINUE 

5.  DISPLAY 

6.  QUIT 

Various  options  can  be  given  with  these  commands.   Options  for 
a  command  follow  the  command  giving  the  primary  actions.   The 
end  of  a  command  is  indicated  by  semicolon.   A  command  can  be 
continued  on  more  than  one  card  and  no  continuation  code  is 
required. 


List  of  Primary  Keywords 

All  the  primary  keywords  of  the  ASPEN  input  language  and 
their  functions  are  given  in  Table  2.1.   These  keywords  have 
been  divided  into  many  broad  classes  depending  on  the  category 
of  data  being  entered  by  them. 
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Table  2.1 

List  of  Primary  Keywords 

Keyword 

Function 

GENERAL  DATA 

TITLE 

To  give  a  title  to  the  simulation 

problem. 

DESCRIPTION 

To  give  a  description  of  the  simulation 

problem. 

FLOWSHEET 

To  enter  the  flowsheet  connectivity. 

IN-UNITS 

To  specify  the  global  units  in  which 

data  will  be  entered. 

OUT-UNITS 

To  specify  the  units  in  which  output 

will  be  printed. 

HISTORY 

To  specify  options  for  history  printout. 

RUN-OPTIONS 

To  enter  run  time  options. 

FILES 

To  give  passwords  for  the  user  data 

files. 

Table  2.1  (continued) 
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Keyword 


Function 


COMPONENTS 


ATTR-COMPS 

SC-COMPS 

COMP-NAMES 

USER-PROPS 
PROP-SOURCES 

PROP-DATA 
PROPERTIES 


PHYSICAL  PROPERTIES 
To  enter  user  given  I.D's  and  data  file 
names  for  the  components  in  the 
simulation. 

To  enter  attributed  components  and 
their  types. 

To  define  the  list  of  super  critical 
components. 

To  give  descriptive  names  to  components 
(for  report) . 

To  define  a  new  user  property. 
To  specify  sources  for  physical 
property  data  retrieval. 
To  enter  physical  property  data. 
To  specify  the  options  for  calculation 
of  physical  properties  in  various 
sections  of  flowsheet. 


m  M 
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Table  2.1  (continued) 


Keyword 


Function 


PROP-OPTIONS 

MP- ROUTE 
SP-ROUTE 

NC-PROPS 


To  define  a  new  option  (primary  route) 
for  calculation  of  physical  properties. 
To  define  a  new  major  property  route. 

To  define  a  new  subordinate  property 
route. 

To  specify  a  list  of  properties  and 
associated  model  names  for  calculation 
of  non-conventional  properties  for  each 
attributed  component  type. 


DEF-STRM-CLASS 

DEF-PHASE-CLASS 

STR.M-CLASS 

DEF-ATTRI3UTES 

STREAM 

STRM- NAMES 


STREAMS 
To  define  a  new  strean  class. 
To  define  a  new  phase  class. 
To  assign  streams  to  different  classes. 
To  give  the  description  of  attributes. 
To  enter  data  for  a  stream. 
To  give  descriptive  names  to  streams 
(for  report) . 


Table  2.1  (continued) 
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Keyword 


Function 


BLOCK 


USER-BLOCK 


UNIT  OPERATIONS 
To  enter  data  for  a  unit  operations 
block. 

To  enter  data  for  a  user  written  unit 
operations  block. 


UTILITIES 

COST-INDEX 
CBLOCK 

USER-CBLOCK 


SIZING  AND  COSTING 
To  specify  and  give  I.D.s  to  the 
utilities  required. 
To  specify  the  global  cost-index. 
To  enter  data  for  a  sizing  and  costing 
block. 

To  enter  data  for  a  user  written  sizing 
and  costing  block. 


ECONOMICS 


ECONOMIC  ANALYSIS 


To  enter  data  for  economic  analysis. 


86 

Table  2.1  (continued) 

Keyword 

Function 

FLOWSHEET  CALCULATIONS 

TEAR-STREAMS 

To  specify  the  tear  streams. 

CONV-TOL 

To  specify  the  convergence  variables 

and  their  tolerances. 

VAR-TYPE 

To  specify  the  types  of  convergence 

variables. 

DES-SPEC 

To  enter  a  design  specification. 

CONV 

To  enter  data  for  a  convergence  block. 

USER-CONV 

To  enter  data  for  a  user  written 

convergence  block. 

INF-PROC 

To  enter  data  for  an  information 

processing  block. 

CONV-ORDER 

To  give  the  order  in  which  convergence 

blocks  will  be  converged. 

SEQUENCE 

To  enter  the  computational  sequence. 

INF-STRM 

To  enter  data  for  an  information  stream 

SENSITIVITY  STUDY 

SENSITIVITY 

To  enter  data  for  sensitivity  study. 

REPORT  WRITING 

REPORT 

To  enter  parameters  for  report  writing. 
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EXAMPLES 

Two  examples  are  included  in  this  section.   These  examples 
show  the  main  features  of  the  ASPEN  input  language. 
Example  1 

This  example  comprises  block  diagram  and  input  language  for 
a  very  simple  vapor  liquid  process.   The  block  diagram  for  the 
process  is  given  in  Figure  2.1.   The  objective  of  this  example 
is  to  show  how  traditional  vapor  liquid  simulation  problems 
will  be  entered  with  ASPEN  input  language.   The  input  data  for 
the  process  is  given  in  Figure  2.  2.    IN-UNITS  is  used  to 
indicate  that  all  the  input  data,  except  pressure,  is  in  engi- 
neering units  and  pressure  is  in  Pascals.   Wherever  data  is  in 
some  other  units,  units  are  given  within  parentheses  immedi- 
ately following  the  data.   Benzene,  Propylene,  and  Cumene  are 
the  three  components  in  the  process  and  the  user  will  be 
refering  to  them  later,  in  the  input  as  CI,  C2  and  C3  respec- 
tively.  Physical  properties  for  the  components  will  be 
calculated  within  a  system  defined  as  standard  option  STDl. 
The  problem  has  a  design  specification  that  the  mole  flow  of 
cumeme  in  stream  S5  should  be  39.8  lb  moles/hr  and  this  speci- 
fication is  to  be  achieved  by  varying  the  tenperature  of  the 
flash. 
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Figure  2.2    Input  Data  for  Example  1 
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INPUT 
TITLE 


"MAVJUFACTURE  OF  CJM£NJE" 


DESCRIPTION   "THIS  IS  A  SAMPLE  PROBLEM  TO  SHOW  MAIN  FEATURES  OF 
ASPFN  INPUT  LANGUAGE." 


FLOWSHEET 
Ml 
Rl 
HI 
Fl 
PI 


IN  =  SI  S7      OUT  =  S? 

IN  =  S2  OUT  =  S'j 

IN  =  S3  OUT  =  S4 

IN  =  S4  Out  =  S5   S^ 

IN  =  56  OUT  =  S7 


IN-UNITS  ENGINEERING   PPES  =  PASCAL 

OUT-UNITS  ENGINEERING 

HISTORY  MSG-LEVFL  =  6 

RUN-OPTIONS  MAX-TIME  =  30   MAX-ERR  =  500 

COMPONENTS  CI   BENZENE  /  C2   PROPYLENE  /  C3   CjMENE 

PROPERTIES  STDOl 


STREAM    SI 
PHASE 
MOLE-FLOW 

STREAM    S7 
PHASE 
MOLE-FLOW 


MIXED   TEMP  =  220  (C.)       PP£S  =  3^ 
CI   40  /  C2   ^0  /  C3   0 


MIXED   TEMP  =  320   PRES  =  J6 
CI   620  /  C2   40  /  c3   0.2 


BLOCK    Ml 
PARAM 

BLOCK    Rl 
STOICH 
EXTENT 

BLOCK    HI 
PARAM 

BLOCK    F] 

PRODUCTS 
PARAM 

BLOCK    PI 
PARAM 


MIXER-REG 

PRES  =  -O.S 

PEACTOR-XTNT 

REACTION  =  1 
REACTION  =  1 


CI 
C2 


1  /  C2 

0.9 


1  /  C3   -1 


heater-pt 

temp  =  300  pres  =  -0.1 

FLASH-PT2 

VAPOR  =  S6   LIQUID  =  SS 
TEMP  =  310   P-^ES  =  1  (ATM) 


PUMP 


RRES  =  36 
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Figure  2 . 2    (continued) 


TEAR-STREAMS  S7 

OES-SPEC    PURITY 

DEFINE       COMP   AS  VALUE  OF  STREAM  Sb  MOLF-FLOW  C3 
SPEC         COMP  =  39. «   TOL  =  0.01 
VARY  TEMP  OF  BLOCK  Fl 


CONV    CI 

MFTHOD 

STREAMS 

SPECS 

param 


9R0Y0EN 
57 

PURTTY 
MAXIT  =  20 


END  DATA 


ai 


Example  2 


This  example  gives  the  input  data  for  the  rigorous  calcu- 
lations of  a  distillation  column.   The  example  shows  how  the 
ASPEN  input  will  look  for  complex  unit  operation  blocks.   The 
distillation  column  being  simulated  is  given  in  Figure  2.3  and 
the  input  data  are  in  Figure  2.4.   All  the  entries  in  this 
example  are  self  explanatory. 

2.3.2.   SUMMARY  OF  SYSTEM  DESIGN 

This  section  summarizes  general  principles  of  the  design 
specifications  for  ASPEN. 

The  ASPEN  system  has  various  new  features  such  as  flexible 
data  structures  to  handle  an  unlimited  number  of  streams  and 
blocks  and  a  capability  to  handle  solid  phases  particularly  for 
coal  conversion  processes.   In  addition,  ASPEN  includes  new 
techniques  on  the  computational  architecture,  physical  property 
estimations,  unit  operation,  sizing,  costing  and  economic  eval- 
uation models.   The  details  on  the  requirements  are  included  in 
an  earlier  document  entitled  "Functional  Specifications  for 
ASPEN. " 
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Figure  2.3 


The  Distillation  Column  for  Example  2 
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NUMBER  OF  THEORETICAL  TRAYS  =  24 
FEEDS  AT  TRAYS  5  J^IID    14 
SIDE  DRAW  FROM  TRAY  19 
PZBGILER  DUTY  10000  Btu/hr 
COLUMN  PRESSURE  300  psia 


DISTILLATE 
S3 


-►SIDE  DRAW 
S4 


> BOTTOMS 
S5 


Figure  2 . 4    Input  Data  for  Example  2 
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INPUT 
TITLE 

FLOWSHEET 

COLUMN 

IN-UNITS 
OUT-UNITS 

COMPONENTS 
PROPERTIES 


"RIGOROUS  DISTILLATION  CALCULATIONS" 

IN  =  SI   S?     OUT  =  S3   n't   S5 
ENGINEER  I  f^G 
ENGINEERING 
C3   PROPANE  /  C^   N-8UTANE  /  CS   N-peNTANE 

STon? 


BLOCK    COLUMN 
PARAM 

FEEDS 

LIO-PROn 

VAP-PROD 

TEMP-EST 

VFLOW-EST 

VCOMP 

V/COMP 

HEATER 

CONG 

STREAM    SI 
PHASE 
MOLE-FLOW 

STREAM    S2 
PHASE 
MOLE-FLOW 


OISTILL-PEG 

^JTPAY  =  24   PTOP  =  300   MAAIT  =  20   hTOL  =  0.1 

MTOL  =  O.OOl 

5    SI  /  U   S2 

19   S4  /  24   S5 

1  S3 

2  20    /    <5       30/16      40/23      50 

2   6000  /  Q   5000  /  16   3500  /  23   1000 
TRAY  =  fl    C3   0.63  /  C4   0.2S  /  CS   0.12 
TRAY  =  16   C3   0.10  /  C4   0,40  /  C5   0.50 
24   10000 
PRES  =  -1.0 


MIXEO   TEMP  =  25   PRFS  =  ?80 
C3   500  /  C4   300  /  C5   lOU 


MIXED   TE^P  =  40   PRES  =  200 
C3   100  /  C4   100  /  C5   30 


END  DATA 
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TO  realize  the  functional  specifications,  ASPEN  has  adopted 
a  variable  length  data  structure  based  on  the  plex  structure 
and  a  system  architecture  in  which  part  of  the  Simulation 
Program  is  generated  by  the  Input  Translator.   The  detailed 
discussions  and  reasons  are  described  first.   In  addition  to 
that,  the  requirements  for  ASPEN  can  be  realized  by  using 
various  key  principles  and  techniques  which  are  shown  in  the 
following  sub-sections. 
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2.3.2.1  System  Architecture 


ASPEN  has  adopted  an  architecture  in  which  the  Main  Calling 
Program  for  a  simulation  is  generated  by  the  System  based  on 
user  input  (see  in  Figure  2.5).   This  is  commonly  known  as  the 
'preprocessor'  type  approach  as  opposed  to  the  'interpreter' 
type  simulators  which  is  a  single  large  stand  alone  program. 

The  reasons  for  doing  this  are:  (i)  ASPEN  has  a  large 
number  and  variety  of  programs  and  all  of  these  programs  are 
not  needed  for  any  one  simulation;  (ii)  the  user  may  insert 
FORTRAN  programs  (either  compiled  or  uncompiled)  or  FORTRAN 
statement  which  then  must  be  assembled,  compiled,  and  linked  to 
the  rest  of  the  system  with  appropriate  calls  generated;  and 
(iii)  the  core  memory  to  store  simulation  data  depends  on  the 
problem  and  it  is  possible  to  tailor  the  core  size  requirements 
to  the  problem  at  hand  by  dimensioning  variables  in  the  sim- 
ulation program  generated  by  the  Input  Translator,   These 
reasons  are  elaborated  below. 

First  the  creation  of  a  single  large  program  would  have  to 
include  all  unit  operations,  sizing  and  costing,  and  physical 
property  models  which  are  part  of  ASPEN.  All  of  these  models 
will  not  be  required  for  any  one  simulation.  As  an  example 
take  the  physical  property  models,  there  may  be  six  different 
equations  of  state  available  and  the  simulation  may  need  only 
one  or  two.   A  vapor-liquid  simulation  would  not  require  any  of 


Figure  2.5  Preprocessor  Structure  of  ASPEN 
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the  solids  handling  equipment  models  or  solid  property  routines 
to  be  available.   All  of  the  programs  in  ASPEN  will  not  con- 
ceivably fit  into  any  computer  core  all  at  once.   Hence  the 
system  could  require  a  complex  overlay  structure  (for  programs 
as  well  as  data)  except  for  virtual  machines. 

Second,  one  of  the  requirements  of  ASPEN  was  that  the  user 
should  be  able  to  handle  FORTRAN  statements  and  programs  (com- 
piled and  uncompiled)  as  part  of  the  input.   This  requires  a 
compile  and  link -edit  step  before  execution.   The  generation  of 
a  calling  program  does  not  add  any  more  complexities  to  the 
system.   Furthermore,  the  user  supplied  FORTRAN  may  be  passed 
to  the  compiler  without  processing. 

Third,  the  intermediate  program  generation  would  allow 
creation  of  a  calling  program  with  properly  dimensioned 
arrays.   This  way  core  requirements  of  the  simulation  can 
be  kept  smaller.   Also,  unwanted  data  may  be  eliminated. 


2.3.2.2  Data  Handling 


ASPEN  is  a  file-oriented  system.   Extensive  use  of  files  in 
secondary  storage  is  made.   This  facilitates  the  following:  1) 
The  ability  to  break  up  the  system  into  modules  which  commun- 
icate via  files,  thus  reducing  program  size  and  complexity;  (2) 
The  storage  of  intermediate  results  for  subsequent  runs;  (3)  On 
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interactive  systems,  the  ability  to  examine  output  before 
printing;  and  4)  The  ability  to  store  commonly  used  data  in 
files  shared  by  all  users.    Table  2.2  lists  various  types  of 
files  in  the  system.   Of  particular  significance  is  a  file 
containing  the  data  structure  of  a  problem  called  the  problem 
data  file.   This  file  keeps  an  image  of  the  data  as  it  exists 
in  core  during  a  simulation.   This  file  may  be  used  in  repeat 
runs.   Modifications  to  the  data  structure  may  be  made  through 
the  input  processor.   During  the  simulation  this  file  may  be 
used  to  store  intermediate  results  so  that  in  case  of  failure 
it  is  not  necessary  to  repeat  all  calculations.   Data  is  read 
from  and  written  back  on  this  file  during  the  simulation.   This 
aspect  of  reading  and  writing  of  data  is  built  into  ASPEN  and 
is  transparent  to  the  programs  using  the  data. 

All  process  data  except  physical  property  constants  are 
stored  in  a  plex  data  structure.*   Data  is  stored  in  the  form 
of  beads.   Each  bead  is  part  of  a  lengthy  FORTRAN  array  called 
the  Plex  Array.   Each  bead  has  associated  with  it  a  bead  number 
which  helps  identify  its  location. 

A  bead  may  be  considered  as  a  list  of  data  items  which 
occupy  contiguous  storage  locations  in  core. 


♦Physical  property  constants  are  stored  in  labeled  COM^^ON 
during  the  calculation  phase. 
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Table  2.2   Types  of  Data  Files  in  the  ASPEN  System 


Type  of  file 


Contents 


Input  data  file 


An  image  of  user's  input  data 


Program  Pile 


The  FORTRAN  programs  generated  by 
the  Input  Translator 


Problem  Data  File 


A  copy  of  the 
describing  th 
contains  all 
process.   Dur 

is  used  as  th 
modifications 
in  the  data  s 
results  of  th 
structure  of 
explained  in 
next  section. 


data  structure 
e  process.   This  file 
information  about  the 
ing  EDITRUNs  the  file 
e  starting  point  for 

Space  is  allocated 
tructure  to  store  the 
e  simulation.   The 
this  file  is 
more  detail  in  the 


Problem  History  File 


File  containing  all  intermediate 
messages  produced  by  the  system 
during  a  run. 


Report  File 


File  containing  all  the  reports 
produced  by  the  system. 


Property  Data  Files 


Pile  containing  physical  property 
constants  for  components. 


Cost  and  Size  Data  Pile 


File  containing  constants  for 
equipment  sizing  and  costing 


The  Problem  Data  File,  Problem  History  File,  and  Report 
Pile  are  printed  at  the  end  of  the  run.  The  files  are  then 
deleted  unless  the  user  has  specified  these  to  be  saved. 
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Data  is  stored  in  the  Problem  Data  File  in  beads.   Each 
bead  has  associated  with  it  a  physical  location  in  the  file. 
This  is  shown  in  Figure  2.6.   Note  that  a  physical  location  may 
be  converted  into  a  record  number  and  an  offset  for  random 
access  purposes.   All  reads  and  writes  on  the  file  are  done  in 
binary  form. 

Data  in  core  memory  resides  in  a  single  large,  one 
dimensional  FORTRAN  array  in  COMMON: 

COMMON/PLEX/3 (NPLEX) 

The  user  may  specify  a  value  of  NPLEX  in  his  data.   This 
plex  array  is  divided  into  equal  size  sections  called  record- 
frames.   The  size  of  a  record-frame  is  set  equal  to  the  size  of 
a  record. 

Data  in  the  file  is  brought  into  core  as  needed.   Thus  if  a 
program  needed  a  specific  bead,  then  the  record(s)  containing 
that  bead  is  brought  into  core  and  the  array  index  of  the  bead 
in  core  is  returned.   The  program  then  can  refer  it  to  the 
contents  of  the  bead  using  its  index  in  the  plex  array. 

2.3.2.3   Flowsheet  Calculations 


Computation  of  heat  and  material  balance,  as  well  as  any 
other  numerical  computation  related  to  a  flowsheet,  requires 
access  to  and  manipulation  of  the  flowsheet  variables.   The 
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Data  in  the  form  of  beads  in  the  data  file 
A  bead  may  consist  of  integers,  floating- 
point values  or  alphanumeric  characters. 
File  address  of  a  bead  is  the  number  of 
integer  words  from  the  beginning  of  the 
file.   This  may  be  converted  into  a  record 
number  and  offset  within  a  record. 
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2. 


3. 


4. 


data  structure  for  ASPEN  has  been  designed  so  that  the 
following  objectives  can  be  achieved. 

1.    Flowsheet  description  is  independent  of  the  numerical 

procedure  employed  to  carry  out  calculations. 

Numerical  algorithm  procedures  do  not  contain  any 

information  specific  to  the  data  structure  describing 

the  flowsheet. 

The  user  can  access  any  flowsheet  variable  and  carry 
out  any  tranformation  of  variables. 
Transformation  of  variables  is  accomplished  by  the 
user  entering  program  statements  in  FORTRAN.   The  user 
can  employ  any  desired  name  for  a  particular  variable. 
The  user  can  prescribe  functions  of  flowsheet  vari- 
ables which  are  to  be  computed  (design  specifications). 
Calculation  procedures  can  access  heat  and  material  as 
well  as  sizing  and  costing  data. 

The  data  structure  allows  simultaneous  convergence  of 
heat  and  material  balances  and  design  specifications. 
The  user  can  specify  as  a  convergence  routine  a  user- 
written  routine. 

In  order  to  satisfy  these  objectives,  the  following 
decisions  have  been  made: 

I.  A  convergence  block  does  not  break  a  tear  stream. 
It  merely  "reads"  current  values,  carries  out  one 
iteration  and  stores  back  the  new  values. 


5. 


6. 


7. 


8. 
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4. 


5. 


2.  A  copy  of  the  values  of  stream  variables  at  the 
last  iteration  is  kept  in  the  retention  area  of  the 
convergence  block. 

3.  There  is  a  directory  of  accessed  variables.   It 
contains  all  the  information  required  to  locate  a 
variable  in  the  flowsheet  data  structure. 
All  convergence  algorithms  (subroutines)  have  the 
same  argument  list. 

There  is  a  single  interface  routine  (convergence 
block)  between  a  numerical  algorithm  routine  and  the 
flowsheet  data  structure.   The  interface  routine 
copies  all  variables  into  local  arrays,  computes 
required  function  values  and  delivers  them  to  the 
numerical  algorithm. 

6.  In  order  to  carry  out  any  desired  calculation,  using 
flowsheet  variables,  an  information  processing  block 
exists.   It  enables  a  user  to  access  any  variable,  use 
his  own  subprograms,  enter  FORTRAN  statements,  etc. 

7,  To  transfer  variables  not  contained  in  a  process 
stream,  from  one  block  or  a  stream  to  another,  an 
explicit  information  stream  can  be  used.   Note  that  a 
heat  stream  need  not  be  an  information  stream,  if  the 
incident  blocks  know  how  to  process  it. 

Main  points  of  the  data  structure  will  be  discussed  in 
somewhat  greater  detail  next. 


'v  \4:0c%rufntmf ' 
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Variables  to  be  Converged  Upon 

A  process  stream  is  usually  described  by  more  variables 
than  is  necessary  in  order  to  completely  describe  the  thermo- 
dynamic state  of  the  stream.   Therefore,  only  a  subset  of 
stream  variables  is  converged  upon.   For  a  conventional  vapor- 
liquid  equilibrium  stream  convergence  variables  may,  for 
instance,  be  the  component  flowrates  and  the  stream  enthalpy. 

The  existence  of  the  attributed  components  and  non-conven- 
tional component  dictate  that  a  user  should  be  able  to  specify 
what  variables  are  to  be  the  iteration  variables  and  what  type 
of  convergence  procedure  to  apply  to  them.   Consequently,  in 
the  ASPEN  system  the  user  can  specify  an  independent  set  of 
stream  variables  of  his  own  choice  as  the  iteration  variables. 

All  stream  variables  are  explicit  iteration  variables, 
i.e.,  they  are  computed  as 


x(k)  =  £  (x(k-l)) 


The  convergence  algorithm  finds  a  zero  of  the  functi 


on 


f(k)  ,  xC^)  -  x('<-l) 


Since  the  flowsheet  does  not  contain  two  copies  of  every 
stream  iterated  upon,  the  numerical  procedure  (convergence 
block)  keeps  in  the  retention  area  the  values  of  the  inde- 
pendent variables  at  the  last  iteration. 
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Some  of  the  iteration  variables  may  be  converged  by  one 
convergence  method  and  some  by  the  others.   In  particular,  a 
subset  of  the  stream  variables  may,  in  a  sequential  modular 
computation,  be  converged  by  direct  substitution  and  the 
remaining  stream  variables  may  be  converged  by  the  Wegstein's 
algorithm.   Hence,  associated  with  every  variable  there  is  a 
variable  type.   It  defines  if  a  variable  is  to  be  converged  by 
direct  sustitution  or  by  a  given  convergence  algorithm. 

Another  feature  of  ASPEN  worth  mentioning  is  the  scaling  of 
the  iteration  variables.   Some  numerical  algorithms  require 
that  all  the  variables  be  of  the  same  order  of  magnitude.   The 
ASPEN  data  structure  accomodates  the  scaling  factor  for  each 
iteration  variable. 


Design  Specifications 

Simulation  of  a  chemical  process  is  often  carried  out  in 
order  to  meet  some  design  specification  (e.g.,  quantitity  of 
the  product  composition  etc.).   Design  specifications  may  vary 
from  a  simple  requirement  that  a  variable  attains  a  given  value 
to  the  requirement  that  a  complicated  transformation  (function) 
of  some  variables  attains  a  certain  value. 

In  ASPEN  each  design  specification  is  considered  as  an 
equation.   It  is  to  be  noted  that  a  design  specification,  as 
stated  by  the  user,  simply  defines  a  procedure  to  compute  the 
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function  value.   For  instance,  if  the  requirement  is  that  a 
temperature  of  a  stream  S2  be  50.0  degrees,  then  the  current 
function  value  is  computed  as 

f  =  T(S2)-50.0 
When  the  design  requirement  is  met,  the  function  value  is  zero. 

Apart  from  the  procedure  to  compute  the  function  value,  a 
user  has  to  specify  what  variable  to  manipulate  in  order  to 
find  the  zero  of  the  design  equation. 

User  supplied  design  specifications  are  converted  by  the 
ASPEN  input  processor  in  a  single  subroutine.   Any  given  subset 
of  design  specification  functions  can  be  computed  by  a  single 
call  to  the  generated  subroutine.   This  enables  a  user  to 
specify  easily  what  design  specification  to  converge  simul- 
taneously. 

If  the  convergence  algorithm  (e.g.,  simultaneous  modular) 
requires  partial  derivatives  of  a  design  specification  with 
respect  to  the  variables  appearing  in  the  equation,  a  user  is 
expected  to  provide  FORTRAN  statements  for  computation  of  the 
partial  derivatives. 

As  a  part  of  the  design  specification  statement,  a  user 
may  supply  his  own  FORTRAN  code  which  carries  out  any  desired 
computation.   Such  code  is  included  as  a  part  of  the  design 
specification  subroutine  generated  by  the  ASPEN  preprocessor. 
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Sequential  Modular  Algorithm 

Structuring  of  the  sequential  modular  computation  consists 
of: 

Analysis  of  the  cyclic  flow  of  information  and/or 

material  and/or  energy. 

Tearing  of  the  recycle  loops. 

Preparation  of  the  data  for  the  convergence  procedures, 

Generation  of  the  computational  sequence. 
The  ASPEN  system  partitions  the  process  flowsheet  into 
maximal  cyclic  subsystems  (parts  of  the  flowsheet  which  are  to 
be  converged  prior  to  array  computation  of  the  downstream  sub- 
systems) .   Tearing  of  the  recycle  loops  is  aimed  at  achieving 
the  best  convergence  properties  of  the  resulting  algorithm. 
Iteration  variables  are  then  divided  into  subsets  of  variables 
to  be  converged  simultaneously  and  appropriate  convergence 
blocks  are  established.   Finally,  the  system  generates  the 
computational  sequence. 

Algorithmic  analysis  of  the  flowsheet  equations  is  carried 
out  whenever  the  user  changes  the  flow  of  information  in  the 
flowsheet.   The  results  are  compared  with  the  user  specifica- 
tions (e.g.,  user  specifies  tear  streams)  and  appropriate 
diagnostic  analysis  is  carried  out.   However,  the  user's 
specifications  always  override  the  system  results. 
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Since  the  flowsheet  description  does  not  depend  on  the 
convergence  procedure,  a  tear  stream  does  not  enter  into  and 
then  leave  a  convergence  block.   Every  tear  stream  is  repre- 
sented as  a  single  stream.   This  allows  us  to  minimize  changes 
in  the  ASPEN  data  structures  if  the  user  desires  to  change  any 
of  the  following: 

(i)   the  set  of  tear  streams 
(ii)   the  subsets  of  tear  variables  to  be  converged 
simultaneously 
(iii)   the  order  in  which  to  converge  the  subsets  of 
variables. 


Numerical  Blocks 

A  numerical  block  represents  a  procedure  to  carry  out  any 
desired  transformation  of  (some  of)  the  flowsheet  variables. 
Special  cases  of  a  numerical  block  are 

(i)   convergence  and/or  control  block 
(ii)   optimization  block 
(iii)   information  processing  block 

A  numerical  block  accesses  specified  flowsheet  variables, 
carries  out  some  calculations  and  changes  values  of  some  of 
the  variables.   The  existence  of  a  numerical  block  is  not  noted 
in  the  flowsheet  description.   For  instance,  the  block  only 
"reads"  current  values  of  the  tear  stream  variables,  computes 
new  values  and  stores  them  in  the  stream. 
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Convergence  and/or  Control  Block 

Traditionally,  a  convergence  block  manipulates  torn  stream 
variables  until  the  heat  and  material  balances  are  computed.   A 
control  block  manipulates  design  variables  until  some  design 
requirements  are  met. 

In  ASPEN,  there  is  no  distinction  between  a  convergence  and 
a  control  block.   They  are  simply  called  convergence  blocks. 
The  data  structure  required  to  accomodate  the  convergence  of 
the  tear  streams  and  design  specifications  is  the  same  for  all 
applications  of  a  convergence  block  in  a  given  simulation. 
Hence,  there  is  only  one  convergence  block  in  the  system. 

Convergence  blocks  do  not  appear  in  the  analysis  of  the 
cyclic  flow  of  information  (loop  analysis) .   This  is  not 
needed,  since  all  the  variables  manipulated  within  a  block 
are  by  definition  iteration  variables. 

If  desired,  one  can  employ  a  user-written  convergence 
routine. 


Information  Processing  Blocks 

An  information  processing  block  represents  a  procedure  to 
access  any  set  of  variables  in  a  flowsheet,  carry  out  any 
desired  transformation  and  then  return  the  computation  to  the 
overall  convergence  algorithm.   The  user  has  to  specify  at  what 
place  in  the  computational  sequence  the  information  processing 
block  is  executed. 
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2.3. 2. 4   Block  Data  Structure 

The  term  block  refers  to  the  ASPEN  flowsheet  element 
representing  a  process  unit.   The  term  model  refers  to  the 
collection  of  subroutines  used  to  model  the  unit  operation. 
This  discussion  is  concerned  with  how  block  data  is  described 
and  stored  and  how  the  model  interfaces  with  this  data  and  the 
main  calling  program  of  the  simulation  program.   Also  discussed 
are  how  model  calculations  are  controlled. 

The  data  constituting  the  block  data  list  for  UOS  model 
computation  may  be  classified  as  follows: 


1.   Specifications 

These  are  input  data  that  must  be  specified  in  order  to 
calculate  outlet  streams  from  inlet  streams,  such  as  the  tem- 
perature and  pressure  of  an  isothermal  flash.   These  variables 
may  be  freed,  with  a  few  exceptions,  to  allow  for  the  satis- 
faction of  design  specifications.   In  this  case  they  are 
manipulated  by  a  control  unit. 
2»   Model  Control  Parameters 

These  are  parameters  necessary  to  control  execution  of 
a  model  such  as  the  maximum  number  of  iterations.   They  are 
always  defaulted  but  may  be  input  by  the  user. 
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3.  Initial  Estimates  of  Internal  Variables 

These  are  estimates  for  initializing  model  calculations, 
such  as  top  and  bottom  tray  composition  estimates  for  a  dis- 
tillation model.   In  general,  the  user  will  not  input  this  kind 
.of  data  unless  a  built-in  model  initialization  procedure  fails 
or  does  not  exist.   When  the  user  does  input  his  data  the 
amount  may  be  variable,  for  example,  intermediate  tray  composi- 
tions as  well  as  top  and  bottom  tray  compositions.   Estimates 
should  be  stored  separately  from  internal  variable  current 
values  both  for  documentation  and  possible  later  re-initial- 
ization.  This  data  cannot  be  manipulated  or  sampled  by  a 
control  unit. 

4.  Retention  Variables 

These  are  all  of  the  model  internal  variables  that  must  be 
saved  in  order  to  restart  model  computations  without  full  or 
even  partial  re-initialization  on  subsequent  passes.   Basically 
this  will  be  the  iteration  variables  of  a  model's  convergence 
procedure.   This  data  cannot  be  input  nor  may  it  be  manipulated 
by  a  control  unit.   It  may  however  be  sampled  by  a  control 
unit.   The  above  definition  of  retention  variables  reflects 
a  decision  to  sacrifice  in-core  and  file  storage  in  favor  of 
reduced  execution  time  for  recycle  and  restart  problems. 

5.  Calculated  Results 

These  are  results  not  outlet  streams  or  retention  vari- 
ables, such  as  heat  duty.   They  may  be  sampled,  but  not 
manipulated  by  control  units. 


112 


6 .  Physical  Property  Route  Identifiers 

These  identify  the  route  or  routes  to  be  used  for  computing 
physical  properties  needed  by  the  model. 

7.  Work  Area  Location 

This  is  a  location  of  array  space  for  internal  variables 
that  are  not  saved  as  retention  variables.   A  labelled  common 
WORK  is  provided  for  these  arrays. 

8 .  Inlet  Stream  Identification 
5-   Outlet  Stream  Identification 
10 .  Simulation  Control  Parameters 

These  parameters  are  information  about  the  block  needed 
by  the  executive  or  model,  but  not  actually  block  data  in  an 
engineering  or  mathematical  sense,  for  example,  the  block 
history  file  diagnostic  level.   We  refer  to  the  above 
information  as  the  block  data  list  or  block  bead. 

The  distinction  between  retention  variables  and  results 
variables  is  quite  important.   ASPEN  takes  the  point  of  view 
that  a  process  simulator  is  actually  solving  a  large  number  of 
simultaneous  nonlinear  equations  and  that  a  unit  operations 
model  merely  represents  a  partition  of  this  set  of  equations. 
Retention  variables  are  basically  the  iteration  variables 
associated  with  this  partition.   The  ASPEN  concept  is  that  the 
iteration  variables  of  a  model  should  be  stored  in  the  block 
data  list  of  a  block  at  the  completion  of  a  pass,  and  that 
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calculations  should  be  restarted  from  these  values  on  the  next 
pass.   In  other  words  the  data  structure  of  ASPEN  includes  all 
the  system  iteration  variables,  stream  and  block  internal.   The 
function  of  the  block  model  is  to  converge  some  partition  of 
the  full  set  of  system  equations.   Model  initialization  calcu- 
lations are  done  only  in  the  first  pass  of  a  model.   On  sub- 
sequent passes  the  model  iterations  are  simply  restarted  from 
the  previous  solution  at  new  inlet  stream  conditions.   Results, 
on  the  other  hand,  are  variables  that  may  be  calculated  by  the 
model  but  that  are  not  needed  for  convergence  of  the  flowsheet 
heat  and  material  balance. 

The  block  list  definition  for  each  model  is  fixed.   Block 
data  is  made  up  of  scalars  and  variable  dimension  arrays.   The 
scalars  include  any  variable  dimensions  for  arrays.   For  each 
array  a  pointer  will  be  associated  with  it.   For  work  arrays 
the  pointer  will  point  to  a  scratch  area  (COMMON/WORK/) .   The 
inlet  and  outlet  stream  identifications  are  actually  arrays  of 
pointers  to  streams. 

The  block  list  definition  must  be  known  to  the  input 
processor,  the  UOS  model,  the  sizing  and  costing  system,  and 
the  report  writer.   The  writer  of  the  UOS  model  will  define 
most  of  the  block  data  list.   The  definition  of  the  rest  of  the 
list  is  a  part  of  the  system  design.   The  writer  of  a  model 
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will  define  his  block  data  list  by  use  of  a  model  table.   The 
table  will  include  information  on  how  to  read  input  data  by 
keyword,  allocate  storage,  supply  default  values,  check  limits, 
convert  units,  and  report  data. 

The  alternative  to  the  table  driven  system  is  an  input 
processing  and  output  processing  routine  for  each  model.   This 
is  undesirable  since  the  executive  should  not  require  modific- 
ation simply  to  add  a  new  model  to  the  system,  nor  should  the 
model  writer  be  required  to  know  the  internal  details  of  the 
executive. 


Plex  Data  Structure-Model  Interface 

A  general  principle  is  adopted  that  the  UOS  models  and 
lower  level  routines  should  be  isolated  as  much  as  possible 
from  the  plex  data  structure.   The  goal  is  to  write  UOS  models 
using  mnemonically  named,  properly  subscripted  arrays  rather 
than  plex  addresses.   For  example,  a  distillation  column  model 
should  be  written  using  a  liquid  mole  fraction  arrray  named  X 
having  dimensions  of  the  number  of  trays  and  the  number  of 
components  instead  of  having  to  calculate  the  plex  address  of 
each  desired  data  element.   This  will  be  accomplished  by  over- 
laying FORTRAN  arrays  onto  the  plex  data  structure.   There  will 
be  little,  if  any,  copying  of  plex  data  into  arrays.   The  over- 
laying will  be  accomplished  through  subroutine  calls  whose 
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dummy  arguments  are  arrays  and  array  dimensions  and  whose 
actual  arguments  are  plex  elements.   The  only  constraint  on 
the  plex  data  structure  is  that  the  data  to  be  overlayed  by  a 
FORTRAN  array  be  stored  contiguously  in  the  same  order  as  the 
FORTRAN  array  data. 

This  isolation  principle  can  be  followed  completely  with 
block  data  and  to  a  large  extent  with  stream  data.   Stream  data 
are  more  difficult  to  overlay  with  arrays  for  two  reasons. 
First,  the  number  of  streams  connected  to  a  model  need  not  be 
limited,  and  second,  several  different  stream  classes  may  be 
valid  as  inputs  or  outputs  to  a  given  model.   In  contrast,  the 
structure  of  a  block  data  list  is  fixed  and  known.   To  facil- 
itate stream  data  addressing  a  set  of  stream  data  locator 
function  subprograms  will  be  provided.   These  functions  will 
return  the  location  of  a  data  array  or  item  so  that  the  stream 
processing  will  be  independent  of  the  stream  plex  data  struc- 
ture.  These  locator  functions  are  intended  to  be  used  only 
once  per  model  call,  not  every  time  a  stream  data  item  is 
needed. 

The  main  advantage  of  the  isolation  principle  is  that  it 
will  make  UOS  models  and  lower  level  routines  easier  to  write, 
read,  document,  and  maintain.   It  should  also  make  them  more 
efficient  since  array  addresses  will  be  computed  by  FORTRAN 
rather  than  the  integer  arithmetic  required  to  locate  plex  data 
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items.   It  should  be  emphasized  that  the  isolation  principle  is 
in  no  way  an  abandonment  of  the  plex  concept  which  is  ideally 
suited  for  the  generation  of  data  structures  for  process 
simulation.   Rather  it  is  a  means  of  making  efficient  use  of 
the  plex  data  structure,  once  it  has  been  created,  in  the 
actual  simulation  models. 


Calculation  Control 

ASPEN  has  two  calculation  control  flags,  the  Energy  Balance 
flag  and  the  Results  flag. 

The  Energy  Balance  flag  is  used  to  control  the  calculation 
of  outlet  stream  enthalpy  when  this  calculation  is  optional. 
This  flag  is  used  in  conjunction  with  simple  (mixer,  splitter, 
etc.)  models  to  provide  a  "mass  balance  only"  capability. 

The  Results  flag  is  used  to  control  the  calculation  of 
model  results  not  normally  needed  for  convergence  of  the 
flowsheet  Heat  and  Material  Balance.   They  are  calculated 
during  a  Results  Pass  at  the  end  of  the  simulation. 

These  calculation  control  flags  are  discussed  in  more 
detail  in  Appendix  C. 
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2.3.2.5   Stream  Data  Structure 

ASPEN  streams  represent  the  flow  of  material  and/or  infor- 
mation between  blocks  and  into  or  out  of  the  system.   The  data 
structure  and  processing  procedures  adopted  for  streams  must  be 
able  to; 

1.  Accomodate  multiple  liquid  and  solid  phases.   These  phases, 
or  some  subset  of  them,  may  or  may  not  be  in  thermal, 
phase,  or  chemical  equilibrium. 

2.  Represent  components  not  characterized  by  pure  chemical 
compounds  or  pseudo-compounds.   Stream  data  must  include 
the  data  required  to  characterize  these  non-conventional 
components. 

3.  Accomodate  non-conventional  attributes  of  streams,  phases, 
or  components  such  as  the  particle  size  distribution  for  a 
solid  phase. 

4.  Accomodate  conventional  (vapor-liquid)  streams  with  a 
minimum  of  additional  complexity  when  compared  to  existing 
simulators. 


Elements  of  a  Stream 

An  ASPEN  stream  is  merely  a  collection  of  phases  and/or 
attributes.   All  process  data  is  associated  with  the  phases  or 
attributes  of  a  stream  and  not  directly  with  the  stream.   These 
terms  are  described  below. 
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A  stream  is  defined  in  ASPEN  as  a  collection  of  phases 
flowing  together  with  no  heat,  mass,  or  momentum  transfer 
between  them.   A  stream  may  optionally  include  a  collection 
of  stream,  phase,  or  component  attributes.   A  stream  containing 
no  phases  but  containing  stream  attributes  is  an  information 
stream. 

Phases  represent  the  actual  flow  of  material.   Phases  need 
not  be  true  chemical  phases  but  must  be  identified  as  either 
vapor,  liquid,  solid,  or  mixed.   Mixed  phases  are  used  to 
represent  any  mixture  of  actual  phases  in  equilibrium.   Most 
conventional  process  simulators  have  streams  that  consist  of 
a  single  mixed  phase. 

Conventional  phases  are  made  up  of  conventional  components 
and  non-conventional  phases  are  made  up  of  non-conventional 
components.   These  types  of  components  are  discussed  further 
in  Section  3.1.2.1.   Thus  we  have  characterized  phases  in  two 
independent  ways. 

1.  A  phase  may  be 

vapor,  or 
liquid,  or 
solid,  or 
mixed. 

2.  A  phase  may  be 

conventional,  or 
non-convencional. 
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Theoretically  any  combination  is  possible.   However,  we  antici- 
pate the  following  phases  to  be  the  most  applicable  to  coal 
conversion  simulation. 

mixed  -  conventional 

solid  -  conventional 

solid  -  non-conventional 
The  process  data  associated  with  a  conventional  phases  is: 

Component  molar  flow  rate 

Total  molar  flow  rate 

Temperature 

Pressure 

Specific  enthalpy 

Molar  vapor  fraction 

Molar  liquid  fraction 

Specific  entropy 

Density 

Molecular  weight 
The  process  data  associated  with  a  non-conventional  phase  is: 

Component  mass  flow  rate 

Total  mass  flow  rate 

Temperature 

Pressure 

Specific  enthalpy 

Specific  entropy 

Density 
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For  a  particular  phase  at  a  particular  time  during  a  simula- 
tion, any  or  all  of  the  above  information  may  be  missing,  which 
will  be  indicated  by  a  MISSING  DATA  code. 

An  attribute  is  defined  as  being  a  set  of  data,  associated 
with  a  stream,  required  by  a  simulator  in  addition  to  the  prop- 
erties listed  above  for  phases.   The  attribute  type  defines  a 
particular  set  of  data  with  respect  to  both  data  structure  and 
contents. 

An  attribute  may  belong  to  the  stream  directly,  a  phase  of 
the  stream,  or  a  component  of  a  phase.   An  example  of  an  attri- 
bute type  would  be  the  particle  size  distribution  of  a  solid 
phase.   Since  this  data  is  associated  with  a  phase  of  a  stream 
it  is  a  phase  attribute. 

Component  attributes  have  a  more  restricted  meaning  than 
stream  or  phase  attributes.   They  are  the  "state  variable" 
information  required  to  calculate  physical  properties  by  non- 
conventional  methods.   This  is  information  other  than  component 
identification  that  must  be  carried  as  stream  information. 
Each  non-conventional  component  has  only  one  attribute. 
However,  there  may  be  several  component  attribute  types  and 
several  components  of  each  type.   The  attribute  type  for  a 
non-conventional  component  is  identified  by  the  non-conven- 
tional component  type. 
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An  example  of  a  component  attribute  for  a  non-conventional 
component  would  be  the  ultimate  and  proximate  analysis  of 
coal.   It  is  also  permissible  for  conventional  components  to 
have  attributes  since  it  is  sometimes  desirable  to  calculate 
non-conventional  properties  of  conventional  components, 
especially  those  that  are  solids. 

Attribute  type  refers  to  a  specifically  defined  set  of  data 
and  data  structure.   The  data  may  include  variable  dimension 
arrays  but  the  description  of  the  data  remains  fixed.   There- 
fore attribute  types  will  be  described  to  the  system  by  tables 
in  the  same  way  that  model  data  structure  is  described  by 
tables. 

For  example,  the  table  describing  a  particle  size  distri- 
bution phase  attribute  would  indicate  that  the  attribute  data 
consists  of  a  scalar  (number  of  discrete  size  increments)  and 
two  vectors  (increment  limits  and  associated  weight  percents) . 
The  table  would  also  include  information  on  relative  storage 
location,  defaults,  dimensional  units,  etc. 

Attribute  data  is  composed  of  two  distinct  subsets  which  we 
call  "descriptive"  and  "variable".   Descriptive  attribute  data 
is  that  data  required  to  fully  define  the  attribute  but  which 
is  left  free  for  the  user  to  specify.   It  does  not  vary  from 
stream  to  stream  and  is  not  stored  as  stream  data.   An  example 
would  be  the  number  and  size  range  of  increments  describing  a 
particle  size  distribution.   Variable  attribute  data  is  the 
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data  which  actually  varies  during  processing,  that  is  from 
stream  to  stream.   This  data  is  carried  as  variable  stream 
data.   The  actual  fraction  of  material  made  up  of  particles 
within  a  defined  size  range  would  be  variable  attribute  data. 
Variable  stream  data  is  discussed  in  the  following  section. 
When  a  stream  containing  attributes  is  torn  for  recycle 
convergence,  the  variable  attribute  data  associated  with  that 
stream  must  also  be  converged.   Therefore  it  is  necessary  to 
associate  convergence  tolerance  information  with  each  attri- 
bute.  This  information,  like  descriptive  data,  applies  to  all 
streams  containing  the  attribute  and  is  therefore  not  stored  as 
stream  data. 


Stream  Structure 

A  general  stream  data  structure  has  been  developed  that 
allows  a  particular  stream  data  structure  to  be  built  by  the 
ASPEN  system  from  the  kinds  of  elements  discussed  in  the  pre- 
vious section.   A  particular  collection  of  phases  and  attribute 
types  is  called  a  stream  class.   The  purpose  of  the  general 
stream  structure  is  to  provide  the  capability  of  generating 
the  stream  classes  needed  for  specific  purposes  or  types  of 
simulation,  not  to  suggest  that  general  UOS  models  can  be 
developed  to  process  general  streams.   UOS  models  will  apply 
to  a  specific  stream  class  or  a  defined  set  of  stream  classes. 
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ASPEN  will  include  the  classes  required  for  fossil  fuel  con- 
version process  simulation.   Other  stream  classes  may  be  added 
to  the  system  as  needed  along  with  new  or  modified  UOS  models 
to  process  them. 

Stream  classes  are  described  to  the  system  by  tables 
containing  the  number  and  class  of  phases  and  the  number  and 
type  of  stream  attributes.   Similarly,  phase  classes  are 
described  by  tables  containing  the  number  and  type  of  phase 
attributes,  whether  the  phase  is  vapor,  liquid,  solid,  or 
mixed,  and  whether  it  is  conventional  or  non-conventional. 
These  tables  are  much  simpler  than  attribute  tables  since  only 
subordinate  types,  not  actual  data  structures,  are  identified. 
It  should  be  emphasized  that  these  tables  (stream,  phase,  and 
attribute)  are  part  of  the  ASPEN  system  and  not  part  of  the 
user  input.   Their  purpose  is  to  make  it  possible  to  add  or 
modify  classes  without  modifying  the  ASPEN  code. 

The  ASPEN  stream  structure  is  divided  into  two  distinct 
subsets  which  we  call  "descriptive"  and  "variable".   The 
descriptive  subset  consists  of  a  "descriptor"  bead  which 
describes  the  phase  and  attributes  make-up  of  the  stream  and 
contains  pointers  to  any  descriptive  attribute  data.   The 
variable  subset  consists  of  the  component  flow  rates,  temper- 
ature, etc.,  for  each  phase  of  the  stream  and  the  variable 
attribute  data  for  each  attribute  of  the  stream,  in  other 
words,  the  variable  data  is  the  real  (floating  point)  data 
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which  actually  varies  during  processing.   The  consequence  is 
that  only  the  variable  data  need  be  carried  for  each  stream  of 
the  system.   The  descriptive  data  is  stored  only  once  for  each 
stream  class.   If  a  simulation  consisted  of  fifty  streams,  each 
of  the  same  class,  there  would  be  one  stream  descriptor  bead 
and  fifty  stream  beads  in  the  system. 

2.3.2.6   Reruns  Using  ASPEN 

In  a  process  simulation  the  user  may  want  to  make  changes 
to  a  flowsheet  and  repeat  the  calculations.   Some  changes  mean 
altering  a  process  variable  whereas  others  may  mean  altering 
the  data  structure.   ASPEN  allows  three  different  ways  of 
repeating  process  calculations. 


Sensitivity  Studies 

Sensitivity  studies  are  accomplished  using  a  block  similar 
to  a  control  block  to  change  values  of  user  specified  vari- 
ables.  This  block  is  executed  as  the  last  block  in  the  compu- 
tational sequence.   Sensitivity  studies  are  based  on  a  base 
case  from  which  changes  are  made.   The  user  specifies  the 
variables  to  be  monitored  during  the  study.   The  results  of 
the  sensitivity  study  are  presented  in  the  form  of  a  table  of 
independent  variables  and  monitored  variables.   The  user  may 
obtain  additional  results  using  the  diagnostic  print  option. 
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The  extent  to  which  flowsheet  calculations  are  performed 
(starting  block  and  ending  block)  may  be  controlled  separately 
through  the  START=  and  END=  keywords  in  the  convergence  block 
data. 

The  changes  during  sensitivity  studies  are  limited  to 
changing  values  of  process  variables.   These  changes  should 
not  alter  the  data  structure.   If  the  user  wishes  to  make 
multiple  flowsheet  calculations  with  changes  in  the  data 
structure  between  calculations  then  the  EDITRUN  feature  of 
ASPEN  should  be  used. 

Case  Studies 

Case  studies  are  done  by  invoking  the  input  processor 
between  runs.   Each  time  the  input  processor  reads  the  addi- 
tional input  which  contain  changes  to  the  flowsheet.   The 
changes  are  made  in  the  data  structure  and  calculations  are 
repeated.   Since  most  of  the  data  is  unaltered  from  one  run  to 
the  next,  it  is  possible  to  converge  flowsheets  very  quickly. 


Edit  Run  Capabilities 

The  data  file  created  during  a  run  may  be  modified  using 
the  EDIT  capability  in  ASPEN.   There  are  some  restrictions  on 
the  type  of  changes  allowed.   The  changes  during  a  run  can  be 
of  two  types  (1)  changes  that  require  modifying  the  data  struc- 
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ture  called  CHANGE  FLOWSHEET  and  (2)  changes  in  variables  and 
parameters  that  already  exist  on  the  data  structure.   Each  type 
of  change  is  discussed  in  detail  below. 


Change  Data  Runs  (CDATA) 

All  of  the  CDATA  runs  may  be  accomplished  by  addressing  a 
variable  in  the  data  structure  and  resetting  its  value.   There 
are  three  types  of  variables.   LOCAL  variables  are  those  whose 
values  affect  only  a  segment  of  the  data  structure  such  as  a 
block  data  structure  and  stream  data  structure.   Examples  of 
local  variables  are  flow  or  temperature  of  a  stream  and 
parameters  of  a  block.   Changes  in  GLOBAL  variables  affect 
values  stored  in  different  parts  of  the  data  structure.   An 
example  would  be  a  change  in  global  diagnostic  level.   Since 
the  diagnostic  level  is  defaulted  on  many  blocks  all  of  these 
must  be  updated  when  the  global  diagnostic  level  is  changed. 
This  requires  scanning  of  all  the  blocks  and  resetting  the 
diagnostic  level.   This  would  probably  imply  a  change  in 
diagnotic  level  of  all  blocks  that  had  the  previous  global 
diagnostic  level  even  if  it  was  specified  locally  for  that 
block.   Changes  in  global  variables  must  be  specially  handled 
in  the  Input  Processor. 

There  are  certain  variables  whose  value  affects  the  data 
structure.   An  example  is  the  change  in  the  number  of  trays  in 
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a  distillation  column.   Values  of  such  variables,  called  dimen- 
sional quantities  cannot  be  reset  in  a  CDATA  command.   If  the 
user  wishes  to  change  these  then  he  must  replace  the  block  with 
another  block.   Such  dimensional  variables  are  known  to  the 
system  via  the  Block  Tables.   Also  these  variables  will  be 
indicated  as  a  dimensional  quantity  in  the  user's  manuals. 

Another  example  of  a  dimensional  quantity  is  the  number  of 
components  in  the  system.   Since  a  change  in  this  variable 
affects  the  entire  data  structure,  such  changes  will  not  be 
allowed  in  ASPEN. 


Change  Flowsheet  (FLOWSHEET) 

Here  there  are  changes  that  are  local  and  those  that  affect 
the  entry  data  structure.   ASPEN  will  have  a  capability  only 
for  changes  that  are  local.   These  include: 

1.  Addition,  deletion  and  replacement  of  blocks  and 
streams 

2.  Addition  of  new  routes 

3.  Replacement  of  a  component 

4.  New  design  specifications 

5.  Replacement  of  globally  used  beads  e.g.,  routes. 
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2.4  PROGRAMMING  STANDARDS 

Programming  standards  for  the  ASPEN  Project  have  been 
set  up.   The  standards  consist  of  a  series  of  guidelines  in 
writing,  well  documented  and  easily  maintained  programs  in  a 
good  style.   Special  emphasis  has  been  paid  to  program  style 
and  program  portability.   The  document  on  Programming  Standards 
is  included  as  Appendex  A. 

2.5  REVIEW  BY  ADVISORY  COMMITTEE 


A  meeting  of  the  System  Design  Task  Force  of  the  Advisory 
Committee  was  held  on  May  1  &  2  at  M.I.T.  to  review  the  system 
design.   Members  of  the  Advisory  Committee  were  present  for 
this  review.   ASPEN  staff  members  made  brief  presentations  at 
the  opening  of  the  meeting  to  describe  the  system  design.   The 
Task  Force  then  divided  into  four  working  groups  as  follows: 

1.  Input  Language  and  Input  Processor 

2.  Computational  Architecture 

3.  Physical  Properties 

4.  System  and  Data  Structures 

Several  suggestions  were  made  and  these  have  been 
incorporated  into  the  current  design.   The  area  needing  the 
most  reworking  was  the  input  language.   This  has  now  been 
thoroughly  revised  and  a  meeting  was  held  with  DOE  to  discuss 
the  changes. 
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A  working  report  on  the  recommendations  made  at  the  meeting 
has  been  prepared. 

2.6   WORK  FORECAST 


Work  on  this  task  has  been  completed.   No  further 
activities  are  planned  under  this  task  for  the  next  quarter 
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TASK  3:   DEVELOPMENT  OF  PHYSICAL  PROPERTY  SYSTEM 

3.1   WORK  ACCOMPLISHED 

During  the  past  year,  the  two  main  efforts  have  been  the 
preparation  of  the  Functional  Specifications  and  Design 
Specifications.   The  Functional  Specifications  were  documented 
in  Appendix  I  of  the  Sixth  Quarterly  Progress  Report  for  the 
period  ending  November  30,  1977.   The  major  points  are  summar- 
ized below  in  Section  3.1.1.   The  Design  Specifications  were 
completed  during  the  past  quarter,  and  are  presented  in 
abbreviated  form  in  Section  3.1.2.   Other  activities  included 
work  on  the  fitting  of  coal  liquid  property  models,  a  survey 
and  evaluation  of  property  constant  estimation  methods,  and  a 
study  of  activity  coefficient  models  for  electrolytes.   These 
activities  are  reported  in  Sections  3.1.3,  3.1.4,  and  3.1.5, 
respectively. 

3.1.1   FUNCTIONAL  SPECIFICATIONS 


According  to  the  Functional  Specifications  document,  the 
Physical  Property  System  (PPS)  will  be  composed  of  a  set  of 
subsystems  which  consist  of  data  banks,  data  regression  and 
property  constant  estimation  subsystems,  and  a  property  calcu- 
lation subsystem.   All  but  the  latter  will  be  peripheral  sub- 
systems that  are  needed  to  develop  and  store  the  information 
required  to  perform  the  calculations. 
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The  ASPEN  data  banks  will  contain  a  comprehensive  set  of 
physical  property  constants  for  the  vapor,  liquid  and  solid 
phases  of  pure  compounds,  the  important  properties  of  a  number 
of  standard  types  of  coal,  and  the  parameters  of  physical 
property  correlations  for  both  pure  compounds  and  coal.   Any 
number  of  user-provided  data  banks  will  be  accomodated  by  the 
PPS.   All  of  the  data  banks  will  be  accessible  by  the  simu- 
lator executive  system  and  the  peripheral  systems  mentioned 
above.   Proposed  lists  of  contents  of  the  ASPEN  pure  compound 
and  coal  data  banks  were  given  in  Tables  6.1,  6.2,  and  6.3  of 
the  Functional  Specifications. 

The  data,  regression  subsystem  will  enable  the  user  to 
supply  information  in  the  form  of  raw  data  from  which  property 
constants  and/or  correlation  parameters  may  be  determined  by 
linear  or  nonlinear  regression.   The  user  will  be  able  to 
specify  which  models  are  to  be  employed  for  this,  and  which 
constants  and/or  parameters  are  to  be  treated  as  regression 
variables.   The  results  may  be  placed  in  an  output  file  or 
stored  directly  in  one  of  the  data  banks. 

The  constant  estimation  subsystem  will  be  able  to  estimate 
property  constants  not  otherwise  available  using  mainly  struc- 
tural information.   These  results  may  also  be  routed  to  a  data 
bank  or  stored  in  an  output  file  for  later  retrieval.   A  pre- 
liminary list  of  estimation  methods  to  be  included  in  this 
subsystem  was  given  in  Table  6.4  of  the  Functional  Specifica- 
tions. 
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A  variety  of  physical  property  input  modes  will  be  pro- 
vided.  The  information  required  for  a  simulation  will  consist 
of  property  constants,  correlation  parameters  and  calculation 
routing  information.   Any  subset  of  this  information  may  be 
provided  by  the  user  as  direct  input.   The  remainder  will  be 
obtained  from  the  data  banks,  or  from  the  constant  estimation 
or  data  regression  subsystem  output  files. 

The  property  calculation  subsystem  will  contain  a  wide 
range  of  methods  for  calculating  the  properties  of  the  vapor, 
liquid,  and  solid  phases  of  pure  compounds  and  mixtures  as 
functions  of  temperature,  pressure,  and  phase  composition. 
Methods-  will  be  included  for  homogeneous  solid  mixtures  and 
for  liquid  mixtures  containing  electrolytes.   It  will  be  able 
to  calculate  the  properties  of  pseudo-compounds  representing 
boiling  fractions  of  petroleum  and  coal  liquids,  as  well  as 
selected  coal  and  heterogeneous  solid  properties. 

The  properties  that  may  be  calculated  will  include 
volumetric,  thermodynamic,  phase  equilibrium,  and  transport 
properties  of  homogeneous  materials,  and  other  properties 
related  to  the  physical  processing  of  heterogeneous  solids. 
The  routes  which  determine  the  specific  methods  to  be  used  may 
be  completely  specified  by  the  user.   Different  routes  may  be 
employed  in  different  parts  of  a  process. 
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The  available  property  models  will  represent  the  state  of 
the  art  in  equations  of  state,  corresponding  states  corre- 
lations, activity  coefficient  models,  and  other  types  of 
correlations.   New  models  may  be  readily  added  to  the  system 
by  the  user. 

The  property  calculation  subsystem  will  be  directly 
accessible  by  the  ASPEN  Unit  Operations  and  Cost  Estimation 
Systems,  and  by  the  physical  property  data  regression  sub- 
system.  In  addition,  it  will  be  possible  to  use  it  indepen- 
dently of  other  parts  of  ASPEN  through  appropriate  calls  on 
its  subroutines. 

The  proposed  capabilities  of  the  property  calculation 
subsystem  were  outlined  in  Tables  6.6  -  6.9  of  the  Functional 
Specifications.   A  list  of  physical  property  models  that  will 
be  considered  was  given  in  Table  6.10. 


3.1.2   DESIGN  SPECIFICATIONS 


The  main  features  of  the  physical  property  system  design 
are  presented  in  this  section.   The  classification  of  compon- 
ents is  first  discussed  in  Section  3.1.2.1.   The  structure  of 
the  system  is  then  described  in  Section  3.1.2.2  in  terms  of 
the  flow  of  physical  property  information  during  the  data 
file  preparation,  input  translation,  and  simulation  phases. 
Finally,  the  option  set  specification  capability  is  discussed 
in  Section  3.1.2.3. 
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3.1.2.1  Component  Classification 

There  will  be  two  classes  of  components:  conventional  and 
non-conventional.   Conventional  components  are  compounds  or 
pseudo-compounds  that  may  be  characterized  in  terms  of  pure 
compound  properties.   The  usual  thermodynamic  and  transport 
properties  of  these  components  and  their  mixtures  will  be 
calculable  using  a  variety  of  conventional  methods,  according 
to  user-specified  options.   The  flow  rates  of  conventional 
components  in  flowsheet  streams  will  be  carried  in  molar  units 
in  "conventional  phases." 

The  term  "non-conventional"  has  been  adopted  to  refer  to 
components  that  are  not  pure  compounds  (or  pseudo-compounds) , 
and  are  characterized  using  attributes  other  than  pure  com- 
pound properties.   These  attributes  comprise  the  "state 
variable"  information,  such  as  ultimate  and  proximate  analysis 
for  coal,  required  to  calculate  physical  properties.   There 
may  be  several  types  of  non-conventional  components  in  a  sim- 
ulation, each  having  its  own  attribute  list  structure,  with 
any  number  of  components  belonging  to  each  type.   The  physical 
properties  of  a  non-conventional  component  will  be  calculated 
using  a  set  of  models  specified  by  the  user  for  that  compon- 
ent.  The  flow  rates  of  non-conventional  components  in  flow- 
sheet streams  will  be  carried  in  mass  units  in  "non-conven- 
tional phases".   Associated  with  each  component  in  a  non- 
conventional  phase,  will  be  a  set  of  component  attribute 
values  corresponding  to  the  component  type. 
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A  standard  set  of  non-conventional  component  types  will  be 
provided  by  the  system,  each  having  an  associated  attribute 
list  structure.   The  standard  set  might  include  such  component 
types  as  coal,  oil,  ash,  slag,  char,  and  inert  solids.   A 
standard  set  of  calculable  properties  and  property  models  will 
also  be  included  for  the  standard  set.   It  will  be  possible 
for  the  user  to  add  both  new  properties  and/or  new  property 
models  for  component  types  already  present,  and  new  types  with 
new  attribute  list  structures. 

It  is  sometimes  desirable  to  calculate  non-conventional 
properties  for  certain  conventional  components,  especially 
those  that  are  solids.   Since  an  appropriate  set  of  non- 
conventional  component  attributes  must  be  available  for  such 
components,  they  are  referred  to  as  "attributed"  conventional 
components.   The  non-conventional  components  and  attributed 
conventional  components  collectively  comprise  the  set  of 
attributed  components. 


3.1.2.2   Physical  Property  System  Design 

In  discussing  the  design  of  the  physical  property  system, 
it  is  convenient  to  consider  separately  each  of  the  following 
three  phases: 

1.  Data  file  preparation  phase 

2.  Input  translation  phase 

3.  Simulation  phase 
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2. 


The  data  file  preparation  phase  may  involve  any  of  the 
three  peripheral  subsystems:  the  Data  Regression  Subsystem 
(DRS) ,  Property  Constant  Estimation  Subsystem  (PCES)  and  Data 
File  Management  Subsystem  (DFMS) .   Each  of  these  subsystems 
has  its  own  input  language.   It  is  not  possible  to  invoke  them 
using  the  simulator  input  language. 

Each  of  the  subsystems  just  mentioned  may  interact  with 
any  of  a  number  of  physical  property  data  files.   The  general 
characteristics  of  these  files  are  as  follows: 

1.    The  structure  of  all  files  must  conform  to  one  of 
two  well-defined  types. 

The  contents  of  a  file,  both  components  and 
properties,  are  listed  in  its  fixed  structure, 
variable  length  directory. 

A  file  directory  is  addressable  by  the  Input 
Processor  for  data  retrieval,  which  is  keyed  on 
component  and  property  names. 

The  contents  of  a  file  may  be  readily  updated  and 
expanded,  both  components  and  properties,  without 
affecting  the  data  retrieval  functions  of  the  Input 
Processor. 

Using  the  DFMS,  it  will  be  possible  to: 

a)  Create  a  new  file. 

b)  Update  (delete,  modify,  add)  an  existing  file. 

c)  Copy  from  an  existing  file. 

d)  Print  any  subset  of  the  file  contents,  either 
directory  or  data. 


3. 


4. 


5. 
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The  operation  of  the  DFMS  is  shown  schematically  in  Figure  3.1. 

6.    The  file  structures  will  provide  for  documentation 
information  for  each  property  of  each  component. 

The  two  types  of  file  structure  are  designated  simply  as 
Types  1  and  2.   The  Type  1  file  structure  is  most  appropriate 
when  most  of  the  values  are  available  for  a  relatively  compre- 
hensive set  of  properties  common  to  all  the  components  in- 
cluded.  The  Type  2  structure,  on  the  other  hand,  is  well- 
suited  for  storing  a  variety  of  unrelated  data,  where  it  is 
desirable  to  have  a  unique  set  of  properties  for  each 
component. 

Information  flow  in  the  DRS  is  shown  schematically  in 
Figure  3.2.   In  addition  to  providing  raw  data  and  certain 
property  values  as  direct  input,  the  user  may  specify  prop- 
erty, component,  and  file  names  for  retrieval  of  property 
values  from  Types  1  and  2  data  files.   The  output  is  in  the 
form  of  printed  results,  as  well  as  a  Type  2  data  file  that 
may  be  accessed  by  the  Input  Processor. 

Figure  3.3  is  a  schematic  diagram  of  the  information  flow 
in  the  PCES.   Its  configuration  is  similar  to  that  of  the  DRS, 
the  main  difference  being  that  it  does  not  accept  raw  data. 
Like  the  DRS,  it  can  retrieve  property  values  from  Types  1  and 
2  data  files,  and  it  generates  a  Type  2  output  file.   It 
should  be  noted  that  a  DRS  output  file  may  be  a  PCES  input 
file,  and  vice  versa. 
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The  peripheral  systems  just  discussed  are  needed  only  when 
the  user  wishes  to  modify  existing  data  files  or  create  new 
ones.   Hence  the  user  does  not  need  to  invoke  these  systems 
when  all  of  the  physical  property  data  required  for  a  simula- 
tion may  either  be  retrieved  from  existing  data  files,  or 
input  directly  to  the  Input  Processor. 

In  Figure  3.4  the  flow  of  physical  property  information 
in  the  input  translation  phase  and  the  initialization  part  of 
the  simulation  phase  is  represented  schematically.   After 
processing  the  direct  input  provided  by  the  user,  the  Input 
Processor  determines  which  physical  property  models  are 
required  for  the  simulation.   From  tables  stored  in  the 
system,  it  then  compiles  a  list  of  required  physical  property 
constants  and  correlation  parameters.   Those  that  are  not 
provided  as  direct  input  must  then  be  retrieved  from  Types  1 
and  2  data  files  in  accordance  with  the  specified  data 
sources.   All  of  the  required  properties  are  stored  in  the 
Problem  Data  File  for  later  retrieval. 

The  purposes  of  subroutine  PROPLD,  shown  in  Figure  3.4  as 
the  first  step  of  the  simulation  phase,  are  to: 

1.  Establish  properly  dimensioned  physical  property 
labelled  COMMON  areas. 

2.  Load  values  from  the  Problem  Data  File  into  these 
labelled  COMMON'S. 
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3.    Call  a  set  of  initialization  subroutines  which 

initialize  properties  that  depend  on  the  component 
set  but  not  on  state  variables,  and  store  them  in 
appropriate  labelled  COMMON'S. 
PROPLD  is  generated  by  the  Program  Generator  during  the  input 
translation  phase,  using  information  generated  by  the  Input 
Processor. 

The  flow  of  physical  property  information  during  the 
computational  part  of  the  simulation  phase  is  shown  in  Figure 
3.5.   The  Main  Calling  Program  issues  calls  to  UOS  or  CES 
models  in  proper  sequence  as  determined  by  the  Sequence 
Monitor.   When  each  model  is  called,  an  appropriate  conven- 
tional property  option  set  pointer  is  passed  to  it.   This 
pointer  is  a  bead  number  which  points  to  the  proper  option 
set  in  accordance  with  a  user-specified  assignment.   No  other 
physical  property  information  is  transmitted  at  this  time. 

For  conventional  properties,  the  information  passed  to  a 
monitor  consists  of  the  option  set  pointer,  calculation  codes, 
a  component  index  vector,  and  state  variable  values.   The 
calculation  codes  specify  which  properties  are  to  be  calcu- 
lated, and  the  component  index  vector  indicates  which  com- 
ponents are  to  be  included  in  the  calculations.   The  state 
variables  are  temperature,  pressure  and  composition.   The 
monitor  returns  values  of  calculated  properties  to  the  UOS 
or  CES  model. 
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The  monitor  issues  calls  to  property  model  subroutines  in 
proper  sequence  according  to  the  option  set  pointed  to,  and 
the  properties  requested.   By  far  most  of  the  property  calcu- 
lations are  performed  in  these  subroutines.   Each  subroutine 
contains  a  labelled  COMMON,  having  dummy  dimensions,  for  each 
set  of  property  constants  or  correlation  parameters  that  it 
needs. 

The  subordinate  and  other  intermediate  properties  calcu- 
lated by  either  the  model  subroutines  or  the  monitor  are 
stored  in  labelled  COMMON'S.   They  may  be  retrieved  from  these 
labelled  COMMON'S  by  a  UOS  or  CES  model  in  a  special  case  when 
the  writer  of  the  model  knows  that  those  properties  will  be 
included  in  the  option  set  any  time  the  model  is  invoked. 

As  shown  in  Figure  3.5,  the  configuration  for  non-conven- 
tional properties  is  similar  to  that  for  conventional.   The 
main  difference  is  that  a  monitor  determines  which  models  to 
be  used  by  examining  a  pointer  stored  in  a  labelled  COMMON. 
To  find  the  appropriate  pointer,  the  monitor  indexes  into  the 
labelled  COMMON  using  the  component  index  passed  to  it  by  the 
UOS  or  CES  model. 


3.1.2.3   Physcial  Property  Option  Specification 

The  input  language  provides  the  capability  to  specify 
physical  property  options  at  various  levels,  and  to  assign 
option  sets  to  flowsheet  sections  or  individual  blocks.   At 
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the  highest  level,  the  methods  and  models  used  to  calculate 
conventional  physical  properties  are  defined  using  a  PROP- 
OPTIONS  input  statement.   This  statement  contains  references 
to  information  which  defines  how  to  calculate  any  subset  of 
the  following  "major"  properties: 

equilibrium  ratio 

fugacity  coefficient 

enthalpy 

free  energy 

entropy 

molar  volume 

viscosity 

thermal  conductivity 

diffusion  coefficient 

surface  tension 
For  each  of  the  above  properties  included  in  a  PROP-OPTIONS 
statement,  there  must  be  a  separate  entry  for  each  phase 
(vapor,  liquid  or  solid)  included,  as  well  as  separate  entries 
for  pure  components  and  mixtures  when  both  are  included. 

An  entry  in  a  PROP-OPTIONS  statement  consists  of  a  major 
property  keyword  followed  by  the  identifier  of  a  set  of  major 
property  "routing"  information  that  defines  how  the  property 
indicated  by  the  keyword  is  to  be  calculated.  A   large  number 
of  such  major  property  routes  will  be  provided  by  the  system. 


147 


A  table  will  be  available  to  the  user  in  which  these  routes 
will  be  fully  described  and  their  identifiers  given.   The  user 
may  then  refer  to  any  of  them  in  a  PROP-OPTIONS  statement. 
When  the  standard  major  property  routes  are  not  sufficient, 
the  user  may  construct  one  or  more  major  property  routes, 
either  completely  or  by  modifying  standard  ones. 

Several  standard  option  sets  will  be  provided  by  the 
system.   These  will  contain  commonly  used  combinations  of 
major  property  routes.   Any  of  them  may  be  invoked  by  the  user 
simply  by  naming  them;  one  of  them  will  be  treated  as  a  global 
default.   If  one  or  more  of  the  standard  option  sets  are 
sufficient  for  a  simulation  without  being  modified,  no  PROP- 
OPTIONS  statements  are  required. 

For  each  UOS  or  CES  block  that  requires  conventional  phys- 
ical properties,  there  must  be  one  or  more  designated  sets  of 
property  options.   A  particular  set  may  be  common  to  any 
number  of  blocks,  and  there  may  be  some  blocks  for  which  more 
than  one  set  must  be  designated.   Option  sets  may  be  desig- 
nated using  their  identifiers  for  individual  blocks,  for 
flowsheet  sections,  or  globally. 

From  the  above  discussion,  four  levels  of  complexity  and 
sophistication  in  specifying  physical  properties  may  be 
recognized.   In  order  of  increasing  complexity  they  are: 
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2. 
3. 


1.    Use  of  the  standard  default  option  set  throughout 
the  flowsheet. 

Use  of  one  or  more  specified  standard  option  sets. 
Definition  of  one  or  more  option  sets,  either 
completely  or  by  modifying  standard  ones,  using 
standard  major  property  routes  provided  by  the 
system. 

4.    Definition  of  one  or  more  major  property  routes, 
either  completely  or  by  modifying  standard  ones. 

A  Level  1  user  is  not  required  to  provide  any  information 
about  physical  properties.   \Vhile  this  is  the  ultimate  in 
simplicity,  it  allows  the  user  no  flexibility.   A  Level  2  user 
must  provide  one  or  more  option  set  assignment  statements,  but 
need  not  include  any  PROP-OPTIONS  statements.   Level  2  input 
preparation  is  simpler  than  that  of  FLOWTRAN,  while  still 
providing  greater  flexibility  than  is  available  with  FLOW- 
TRAN.  At  Level  3,  a  user  must  include  a  PROP-OPTIONS  state- 
ment for  each  option  set  he  wishes  to  define.   It  may  be  noted 
that  Level  3  is  approximately  the  same  as  FLOWTRAN  in  complex- 
ity of  user  input,  but  provides  a  great  deal  more  flexibility 
than  FLOWTRA^T. 

It  is  anticipated  that  the  vast  majority  of  ASPEN  users 
would  find  the  first  three  levels  of  physical  property  speci- 
fication to  be  adequate.   Level  4  users  should  be  knowledge- 
able in  applied  thermodynamics,  and  should  be  thoroughly 
familiar  with  the  route  construction  capabilities  of  ASPEN. 
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3.1.3   COAL  LIQUID  PROPERTY  CONDITION 


(2) 


(3) 


A  study  was  made  in  characterizing  coal  liquids  and 
predicting  the  critical  temperature,  molecular  weight, 
critical  pressure,  normal  latent  heat  of  vaporization  and 
acentric  factor  of  coal  liquid  cuts. 

A  survey  made  on  the  production  of  coal  liquids  indicates 
that  there  are  three  general  routes  to  coal  liquid  production: 

(1)    gasification  of  coal  followed  by  the  Fisher-Tropsch 
process, 

pyrolysis  of  coal  followed  by  quality  improvement  of 

resultant  coal  liquid,  and 

coal  dissolution 
Elemental,  compositional  and  SARA  analyses  of  coal  liquids 
indicates  that  coal  liquids  are  different  from  petroleum  oils 
in  the  following  respects: 

(1)  coal  liquids  are  more  aromatic  than  petroleum  oils, 

(2)  coal  liquids  are  more  asphaltenic  and  less 
paraffinic  than  petroleum  oils, 

compounds  present  in  coal  liquids  are  significantly 
smaller  and  have  smaller  side  chains  than  those 
present  in  petroleum  oils,  and 

coal  liquids  have  a  higher  content  of  nitrogen  and 
oxygen  but  contain  less  sulfur  than  petroleum  oils. 


(3) 


(4) 
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Coal  liquids  are  considered  to  consist  of  boiling  fractions 
or  coal  liquid  cuts,  each  characterized  by  a  mean  specific 
gravity  and  boiling  point.   The  boiling  point  and  specific 
gravity  of  a  coal  liquid  cut  is  usually  available.   Estimation 
methods  for  the  physical  property  constants  of  coal  liquid  cuts 
were  developed  in  terms  of  specific  gravity  and  boiling  point. 
The  procedure  employed  involved  first  identifying  all  the  major 
components  present  in  coal  liquids,  and  forty-seven  components 
were  found.   The  next  step  was  the  development  of  estimation 
methods  for  predicting  the  physical  property  constants  of  these 
major  components.   The  resultant  methods  were  assumed  to  work 
well  for  coal  liquid  cuts.   The  methods  developed  were: 
(1)   Critical  Temperature  Estimation 


12.0  +  1.434T^  -  0. 00075771'^ 


-0.01073  API  xTj^  +  0.6122xl0"^T^-^ 

+  0.1328  X  lO'^^T^^  +  0.3902  xio"^API^  x  T^^ 


where 


T 


b 

API  = 


critical  temperature 
boiling  point  (  =  )  °l" 
(i'li.5/S^  )  -  131.5 


=      specific  gravity 


(3-i: 


^> 


(2)   Molecular  Weight  Estimation 


MW  =  -48.16  +  0.1366T.  +  0.6705x10  ^T,^ 

b  b 

+  0.  4  8  27  X  10"^API  XT.  -0  .  4906  x  10~^T,  ^ 

D  b 

-0.  7548  X  lO'^API  X  T.^  -0.4252  x  lO'^^API^  x  a\ 

D  b 
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+  0.8  07  8  X  10~'^API^  xT.^  +0.1315  X  lO'-'-^API^  xT,^ 

b  b 


(3-2) 


where 


T^    {=)  «K 

MW   =   molecular  weight. 


(3)   Critical  Pressure  Estimation 


where 


10.0^ 
14.70 


'   =   critical  pressure  (=)  atm  t  (=)  °k 
c  '   b 

x   =   3.067  +  0.001136  T.  -0.5446  X  10"^T^^ 

b  b 

-0.  2837  X  lO'^^API  X  T,  +  0.  4136  x  lO'^T^"^ 

b  b 

+  0.  4178  X  10"'^API  x  T.  ^  +  0.  2890  x  10"^API^  x  T^ 

b  b 


-0.8075  X  10"^API^  X  T,  ^ 

b 


3-3} 


(4)   Normal  Latent  Heat  of  Vaporization 


V, 


=    1.987  T      (3.9  8T        -3.9  38  +  1.555    InP    )/(1.07-T,      )  (3-4 


be 
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where 


L    =  normal  latent  heat  of  vaporization  (=)  cal/g-mol 

b 
P   (=)  atm,  calculated  by  equation  (3-3) 

T,   =  T,  /T 
be     b   G 

T^    (=)  °K 

T   (=)  °K,  calculated  by  equation  (3-1) 


(5)   Acentric   Factor  Estimation 

P 


0)   =   -log 


■|^  (at  T^  =  T/T^)  -  1.0 


where 


oi    =  acentric   factor 


P,,^„  =  vapor  pressure  (  =  )  atm,  calculated  by 

V  a£J 

regressed  SWAP  vapor  pressure  expression 


P    (=)  atm,  calculated  by  equation  (3-3) 
T^   (=)  "K,  calculated  by  equation  (3-1) 


Table  3.4  compares  these  correlations  against  existing 
ones.   These  correlations  were  tested  on  47  compounds  commonly 
present  in  coal  liquids.   (See  Seventh  Quarterly  Progress 
Report  for  more  details.) 
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3.1.4   PROPERTY  CONSTANT  ESTIMATION  SUBSYSTEM 


The  purpose  of  the  Property  Constant  Estimation  Subsystem 
(PCES)  is  to  estimate  property  constants,  not  otherwise 
available,  using  mainly  structural  information.   Its  operation 
is  discussed  briefly  in  Section  3.1.2.2. 

In  accordance  with  the  recommendation  of  the  Functional 
Modules  Task  Force  (see  Seventh  QPR,  p.  114) ,  it  was  decided 
not  to  implement  this  subsystem  in  the  basic  version  of 
ASPEN.   However,  much  of  the  work  on  evaluating  and  selecting 
estimation  methods  had  already  been  done  at  the  time  of  this 
decision.   The  conclusions  of  this  work  are  reported  in  Table 
3.1;  a  tabulation  of  the  methods  selected  along  with  the 
information  required  by  each.   All  of  the  methods  listed  have 
been  coded  and  tested  except  those  for  the  ideal  gas 
properties.   The  symbols  are  defined  in  Table  3.2. 

In  addition  to  the  methods  listed  in  Table  3.1,  the  PCES 
will  contain  the  Cavett  correlations  for  the  properties  of 
petroleum  liquids,  the  correlations  described  in  Section  3.1.3 
for  coal  liquids,  and  the  UNIFAC  equation  for  infinite 
dilution  binary  pair  activity  coefficients. 
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TABLE  3 . 1 


ESTIMATED  PURE  COMPOUND  PHYSICAL  PROPERTY 
CONSTANTS  AND  ESTIMATION  METHODS 


QUANTITY 


METHOD 


Lydersen 
Nokay-Spencer- Dauber t 


REQUIRED 
INFORMATION* 


T^,  SI 

T,  ,  sp.gr.  @  60°F 


Lydersen 
Forman-Thodos 


M,  SI 

SI 


V 


Lydersen 

Reidel 

Vetere 


SI 


^c'  ^C  ^b 
SI 


Definition 
Garcia-Barcena 


T  ,  P  ,  V 
c    c'   c 

SI 


OJ 


P°^(T) 


Definition 

Edmister 

Lee-Kesler 

Stiel-Thodos 
Ogata-Tsuchida 

Riedel 
Gomez-Nieto-Thodos 

Smith-Winnick-Abrams- 
Prausnitz 


P°^(T^=  .7) 

^c'  ^c'  ^b 
^C  ^c   ^b 


SI 
SI 


^c'  ^c'  ^b 
^c'  ^c'  ^b'  '"* 


Tj^(or  B.P.  :§  lOmmHg)  ,  SI 
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TABLE  3 . 1 


;  CONTINUED) 


QUANTITY 


.VAP 


Ah 


Ah^ 


,VAP 


(T) 


METHOD 


Vetere 

Watson  (extended; 

Pitzer 

Halm-Stiel 

Chueh-Swanson 


REQUIRED 
INFORMATION* 


T  ,  P    T. 
c    c ,   b 

qVAP 

Ah   ^  ,  T   ^,  T  ,  6 
ref     ref    c 

T^,  0) 


oVAP    oL    ^o^ 
ref  '  ^ref  ^Pref 


mt: 


Haggenmacher 
Lyckman-Eckert-Prausnitz 


^C  'b'  ^c,  P°  '  ^' 


,L 


cf,T, 


Lyman-Danner 


Yuan-Stiel 


T^,  0),  C^^^(T),  X 


Definition 


Gomez-Nieto-Thodos 


Halm-Stiel-Vetere 


P*^"^,:,  T   .,  P  ,  T  ,  OJ 
'^ref    ref   c    c 

P?ef'  ^ref  ^C  '" 


C°^°(T) 


Benson 
Benson-O'Neal 


SI 

SI 


.,  oI3 

I. 


Benson 

Franklin-Verma-Doraiswair.y 

Anderson-Bever-Watson 


SI 
SI 
SI 


TABLE  3.1     (CONTINUED) 
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QUANTITY 


METHOD 


Benson 
Anderson-Beyer-Watson 


REQUIRED 
INFORMATION* 


SI 
SI 


Ag: 


,IG 


vanKrevelen-Chermin 
Standard  relation 


SI 

.  oIG   .,  oIG 
As^   ,  Ah^ 


a ,    z/k 


n°''(T) 


Tee-Go toh-Stewart 
(Lennard- Jones ) 

Brokaw  (Stockmayer) 


Reichenberg  (low  pressure) 


c   c 


^b'  ^b  '  ^p 


M,  T^,  SI 


n^'^CT) 


vanVelzen-Cordozo-Langenkamp 
(low  temperature) 


SI 


k^^(T) 


Roy-Thodos  (low  pressure] 


T^,  P^,  M,  SI 


C"' 


5^(T,P) 


Robbins-Kingrea 


Fuller-Schettler-Giddings 
(low  pressure) 


T ,  vo^  c°^  Ah°^^^ 


^b'  s^ 


M^,  Mg,  SI 


P^(T) 


a^^(T) 


Scheibel 

Hayduck-Laudie  (water) 

Macleod-Sugden 
Brock-Bird-Miller 


oL,„,    oL   oL 


T^,  T^,  v°^  SI 


*SI   =   structural  information 
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TA3LE  3.2 


DEFINITIOM  OF  SYMBOLS  USED  IIJ  TADL5  3.1 


AB 

Ah 

k 

M 

P 
P 

As 
T 


molar  heat  capacity  at  constant  pressure 
binary  molecular  diffusion  coefficient 


molar  free  energy  change 


molar  enthalpy  change 


thermal  conductivity 


molecular  weight 


vapor  pressure 


pressure 


molar  entropy  change 


temperature 


molar  volume 


compressibility  factor 


'A 


Greek  Letters 
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temperature  coefficient  of  Watson  equation  exponent: 


surface  tension 


molecular  distance  oarameter 


£/k 


molecular  force  parameter 


CO 


viscosity 

dipole  moment 
acentric  factor 
Stiel  polar  factor 


Subscr ints 


f 

ref 


normal  boiling  point 
critical  point 
formation 
reference 


Superscripts 


pure  compound 
liquid 
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V 


vaoor 


IG 


VAP 


ideal  gas 


vaporization 
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3.1.5.   ELECTROLYTE  ACTIVITY  COEFFICIENT  MODELS 


Work  was  done  last  year  on  the  modelling  of  electrolyte 
activity  coefficients  at  both  the  University  of  Pennsylvania 
and  at  M.I.T.   The  former  consisted  mainly  of  a  literature 
survey,  resulting  in  a  report  co-authored  by  Rajeev  Gautam 
and  W.D.  Seider  in  January,  1978.   The  report  covers  certain 
theoretical  aspects  of  electrolyte  solutions,  as  well  as  a 
discussion  of  existing  models  for  both  strong  and  volatile 
weak  electrolytes.   It  also  discusses  enthalpy,  entropy,  and 
heat  capacity  of  electrolyte  solutions.   It  includes  an 
example  calculation  of  equilibrium  composition  for  an  aqueous 
solution  of  sodium  sulfite,  bisulfite,  and  sulfate  used  for 
scrubbing  sulfur  dioxide  and  carbon  dioxide  from  power  plant 
flue  gas. 

The  objectives  of  the  M.I.T.  work  were  to: 

1.  Evaluate  the  recent  developments  in  the 
thermodynamics  of  electrolytes. 

2.  Select  from  the  existing  activity  coefficient  models 
those  that  were  the  most  promising  for  further  study, 

3.  Modify  the  model(s)  selected,  if  necessary,  to 
accomodate  the  most  general  electrolyte  systems. 

4.  Test  the  ability  of  the  resulting  model(s)  to 
represent  the  behavior  of  one  or  more  typical 
electrolyte  systems. 
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During  the  past  five  years,  a  number  of  significant 
developments  in  modelling  the  thermodynamics  of  electrolytes 
have  occurred.   In  papers  by  Bromley,  Meissner  and  co-workers, 
and  Pitzer,  methods  were  presented  for  calculation  of  the  mean 
ionic  activity  coefficients  of  many  types  of  strong  electro- 
lytes.  In  addition,  a  thermodynamic  framework  has  been  estab- 
lished by  Edwards  et  al.  (1978)  to  calculate  equilibrium 
vapor-liquid  compositions  for  aqueous  solution  of  one  or  more 
of  the  volatile  weak  electrolytes:  ammonia,  carbon  dioxide, 
hydrogen  sulfide,  sulfur  dioxide  and  hydrogen  cyanide. 

In  most  electrolyte  systems  of  industrial  use,  not  only 
strong  electrolytes  and  weak  electrolytes  but  also  molecular 
species  are  present.   Consider  for  example  the  hot  carbonate 
process,  in  which  the  potassium  carbonate  aqueous  solution  is 
used  as  the  acid  gas  removal  agent  in  coal  conversion  plants. 
Potassium  carbonate  and  potassium  bicarbonate  are  strong  elec- 
trolytes, carbon  dioxide  is  a  weak  electrolyte,  methane,  car- 
bon monoxide,  and  hydrogen  are  molecular  species.   A  unified 
thermodynamic  model  is  required  for  modelling  such  indus- 
trially important  electrolyte  systems. 

In  a  continuing  series  of  papers,  Pitzer  ad  his  co-workers 
(1973)  have  developed  a  very  useful  semi-empirical  equation 
for  electrolyte  systems.   The  basic  equation  is 


G 


EX 


M  R'' 


f(I)  +  H    X..m.m,  +   ^  u 
ij  "^  ^  ^    ijk 


,,  s  -     -  -.•,m.m.m. 
ID  -  J    •  ^,,  i]k  1  ]  K 
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where  G^^  is  the  excess  gibbs  free  energy  for  a  solution 
containing  N^  i<g  of  solvent  and  m^^,  m  j ,  etc.,  are 
molalities  of  solute  species  i,  j,  etc.   Also  f(I)  is  a  func- 
tion of  ionic  strength,  temperature  and  solvent  properties 
expressing  the  effect  of  long-range  electrostatic  forces 
between  ions;   X.^  is  a  second  virial  coefficient  giving  the 
effect  of  short-range  forces  between  species  i  and  j;  U^^jj^  is 
a  corresponding  third  virial  coefficient  for  the  interaction 
of  three  solute  species  i,  j,  and  k. 

Since  the  equation  in  the  above  form  contains  too  many 
interaction  parameters  to  be  practical,  Pitzer  modified  it  by 
defining  a  new  set  of  parameters  representing  certain  combin- 
ations of  the  second  and  third  virial  coefficients.   However, 
these  modifications  were  valid  only  for  strong  electrolyte 
systems.   To  obtain  a  more  general  model,  it  was  necessary  to 
change  Pitzer 's  modified  equation  by  restoring  the  second  and 
third  virial  coefficient  terms"  for  molecule-molecule  and 
molecule-ion  interactions.   From  the  resulting  model,  expres- 
sions for  activity  of  the  solvent,  and  activity  coefficients 
of  ionic  and  molecular  species  were  derived.   It  is  noteworthy 
that  the  derived  expression  for  activity  coefficient  of 
molecular  species  is  consistent  with  the  Setschenow  equation 
normally  used  in  studying  the  salting  out  effect  on  molecular 
species. 
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Although  there  are  many  adjustable  parameters  in  the  modi- 
fied Pitzer's  equation,  they  are  significant  only  when  the 
molalities  of  the  corresponding  solute  species  are  relatively 
large.   For  example,  in  the  CO2-K2CO3  aqueous  solution 
system  encountered  in  the  Hot  Carbonate  Process,  the  molal- 
ities of  the  solute  species  are 


m(K+) 

m(H+) 

m(OH-) 

m(HC03) 

mCCO^) 

m(C02) 


3  -.  10, 

<  lO-^m 

<  10-2m 

0-7, 
0-5m 

<  0.1m 


Thus,  it  may  be  shown  that  there  are  only  six  significant 
parameters  in  this  system. 

The  vapor-liquid  equilibrium  data  of  the  CO^-KnCO-, 
aqueous  solution  system  obtained  by  J.S.  Tosh  and  co-workers 
(1959)  has  been  correlated  successfully  using  the  equations 
derived  in  this  study.   The  six  significant  parameters  were 
adjusted  to  fit  the  data  successfully.   Values  of  the  Henry's 
Law  constant  H  for  the  solution  of  carbon  dioxide  in  water 
were  obtained  from  Ellis  and  Codling's  work  (1963).   Vapor- 
phase  fugacity  coefficients  were  calculated  using  the  method 
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of  Nakamura  et  al.  (1976).   Values  of  the  Debye-Hi ickel 
parameters  were  from  Pitzer  (1976) .   Parameters  for  the 
dissociation  constant  of  carbon  dioxide  are  based  on  data 
reported  by  Clark  (1966). 

Figures  3.6  and  3.7  show  the  experimental  data  and 
correlated  results  of  equilibrium  pressure  of  carbon  dioxide 
over  30  and  40  percent  equivalent  potassium  carbonate  solu- 
tion.  The  circles,  triangles,  squares  and  hexagons  are  the 
experimental  data  at  70,  90,  110,  and  130°C  respectively. 
The  solid  lines  are  the  correlation  results. 

Figure  3.8  shows  the  experimental  data  and  the  correlation 
results  of  equilibrium  pressure  of  water  over  40  percent 
equivalent  potassium  carbonate  solution.   In  view  of  the  fact 
that  the  data  are  widely  scattered,  little  attention  was  given 
to  the  data  of  equilibrium  water  vapor  pressure  during 
correlation. 

The  successful  representation  of  the  vapor-liquid  equi- 
librium data  for  the  potassium  carbonate  system  suggests  that 
the  equations  derived  in  this  study  can  be  used  to  construct  a 
thermodynamic  model  for  electrolyte  systems  of  industrial 
use.   Significant  parameters  can  be  identified  through  a 
careful  analysis  of  the  system  of  interest.   After  the 
experimental  data  are  correlated  by  adjusting  these  param- 
eters, the  resulting  model  should  be  satisfactory  for  use  in 
process  calculations. 


FIGURE      3.6 
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Equilibrium  Pressure  of  Carbon  Dioxide  Over 
30-Percent  Equivalent  Potass,iuin  Carbonate  Solution 


.-/-. 
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FIGURE   3.7 
Equilibrium  Pressure  of  Carbon  Uioxide  Over 
40  Percent  Equivalent  Potassium  Carbonate  Solution 
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FIGURE  ,3.8 
KMuiiibL-ium  Pressure  of  WaCcr  Va()or  Over 
•10  'i  IJquivaient  Potassium  Carbonate  SoiuLion 
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3  .  2   WORK  FORECAST 


During  the  next  quarter  all  efforts  will  be  devoted  to 
implementation  of  the  basic  version  of  ASPEN.   in  the  physical 
properties  sytem,  this  implementation  effort  will  consist  of 
the  following  individual  activities: 

1.    Implementation  of  the  Data  File  Management  Subsystem 
(DFMS) . 

Implementation  of  the  Data  Regression  Subsystem  is 
discussed  under  Task  6. 

Development  of  the  conventional  component  data  bank. 

Development  of  the  coal  data  bank. 

Coding  and  testing  of  the  conventional  thermodynamic 

and  transport  property  models  and  monitors. 

Coding  and  testing  of  the  non-conventional  property 

models  and  monitors. 

Coding  and  testing  of  the  Input  Processor. 
Coding  and  testing  of  the  route  resolution  logic. 
The  basic  version  of  the  DFMS  will  have  all  of  the  fea- 
tures intended  for  the  complete  version  except  unit  conversion 
capability.   Since  the  data  file  contents  will  be  in  SI  units, 
this  means  that  input  to  the  basic  DFMS  must  be  in  SI  units. 

The  initial  form  of  the  basic  conventional  component  pure 
compound  data  bank  will  be  obtained  by  converting  the  FLOWTRAN 


2. 

3. 

4. 
5. 

6. 

7. 
8. 
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data  bank  to  a  Type  1  file  structure.   This  will  be  supple- 
mented by  including  both  additional  properties  and  additional 
components.   Present  plans  are  to  obtain  some  of  the 
additional  data  from  a  data  bank  containing  468  compounds 
developed  by  Professor  R.  C.  Reid  of  M. I.T. 

In  developing  the  coal  data  bank  and  selecting  the  basic 
set  of  non-conventional  property  models,  assistance  will  be 
provided  by  Resource  Engineering  Incorporated  (REI) .   This 
work  will  be  performed  under  an  ASPEN  subcontract  based  on  an 
REI  proposal  entitled:  "ASPEN:  Solids  Handling  Simulation." 

The  basic  set  of  conventional  thermodynamic  and  transport 
property  models  will,  with  a  few  exceptions,  include  only  one 
or  two  models  for  each  property.   A  list  of  models  to  be 
included  is  given  Table  3.3. 
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TABLE  3.3    CONVENTIONAL  PHYSICAL  PROPERTY  MODELS  IN 
BASIC  VERSION  OF  ASPEN 


Property 


Basic  System  Models 


Equations  of  state 
Vapor  enthalpy 
Liquid  enthalpy 

Solid  enthalpy 
Liquid  molar  volume 

Solid  molar  volume 

Liquid  activity  coefficient 


Liquid  fugacity  coefficient 

Liquid  vapor  pressure 

Solid  vapor  pressure 
Vaporization  enthalpy 


Redlich-Kwong 
Redlich-Kwong-Soave 

Yen-Alexander 

Special  model  for  water 

Yen-Alexander 

Cavett 

Special  model  for  water 

Polynomial 

Yen-Woods 
Cavett 

Polynomial 

Scatchard-Hildebrand 
Modified  van  Laar 
Modified  Margules  (water)* 
Modified  Pitzer  (electrolytes) 
Wilson 

Chao-Seader 
Grayson-Streed 

Extended  Antoine 
Cavett 

Antoine 

Watson 


*  Three-suffix  Margules  for  water-hydrocarbon  systems; 
hydrocarbon-hydrocarbon  binary  pair  parameters  obtained 
from  solubility  parameters,  water-hydrocarbon  binarv  oair 
parameters  specified  by  user.  '  ~ 


TABLE  3.3    (CONTINUED) 
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Property 


Viscosity 

Low  pressure  pure  vapor 
Low  pressure  vapor  mixture 
High  pressure  pure  vapor* 
High  pressure  vapor  mixture* 
Low  temperature  pure  liquid 
Low  temperature  liquid  mixture 
High  temperature  pure  liquid* 
High  temperature  liquid  mixture* 


Basic  System  Models 


Chapman-Enskog-Brokaw 

Chapman-Enskog-Brokaw 

Reichenberg 

Dean-Stiel 

Modified  Andrade 

Weighted  average 

Latsou-Stiel 

Latsou-Stiel 


Thermal  conductivity 

Low  pressure  pure  vapor 
High  pressure  pure  vapor* 
Low  pressure  vapor  mixture 
High  pressure  vapor  mixture* 
Pure  liquid 
Liquid  mixture 


Stiel-Thodos 

Stiel-Thodos 

Wassiljewa-Mason-Saxena 

Stiel-Thodos 

Sato-Riedel 

Vredeveld 


Diffusion  coefficient 

Low  pressure  vapor  binary 
High  pressure  vapor  binary* 
Component  in  vapor  mixture 
Liquid  binary 
Component  in  liquid  mixture 


Wilke-Lee 

Dawson-Khoury-Kobayash  i 
Blanc's  law 
Wilke-Chang-Vignes 
Modified  Wilke-Chang 


Surface  tension 

Pure  component 
Mixture 


Modified  Hakim 
Power  law 


*  Low  priority  for  basic  version. 
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TASK  4   DEVELOPMENT  OF  UNIT  OPERATION  SUBSYSTEM 
4.1   WORK  ACCOMPLISHED 

Although  work  on  the  Unit  Operations  Subsystem  has  concen- 
trated on  system  design,  several  projects  were  undertaken  in 
order  to  ensure  that  ASPEN  will  have  the  necessary  unit  opera- 
tions models.   One  aspect  of  this  effort,  software  evaluation, 
is  discussed  as  a  separate  task  (Task  7).   All  other  projects 
are  discussed  in  this  section. 

Although  the  system  design  has  no  real  impact  on  the  engi- 
neering considerations  of  unit  operations  models,  it  does  have 
a  large  impact  on  the  implementation  of  the  models  (interface 
with  calling  program,  physical  property  package,  etc.).   The 
system  design  is  presented  in  detail  in  the  System  Design 
report  and  is  highlighted  in  Section  2.3  of  this  report. 

4. 1. 1   COAL  REACTORS 


Work  accomplished  in  the  area  of  coal  conversion  unit 
operations  involved  a  detailed  study  of  currently  available 
processing  schemes  for  coal  gasification,  liquefaction,  and 
devolatilization.   The  intent  of  this  effort  was  to  become 
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thoroughly  familiar  with  the  range  of  reactions  which  must  be 
handled,  the  range  of  operating  conditions  encountered,  and 
variations  in  reactor  staging  and  pretreatment  unit  operation 
schemes. 

The  literature  has  been  thoroughly  searched  for  mathemat- 
ical models  of  coal  gasification,  liquefaction,  and  devolatil- 
ization.   The  available  models  have  been  reviewed,  catalogued 
and  summarized.   These  models  (available  either  from  the  liter- 
ature or  elsewhere)  have  been  collected  and  analyzed  for  the 
purpose  of  (1)  determining  the  base  capability  expected  of 
ASPEN  in  order  to  interface  easily  with  complex  user-supplied 
models,  and  (2)  determining  which  "simple"  reactor  models  will 
prove  useful  both  in  coal  processing  simulation  and  other  sim- 
ulations, and  therefore  should  be  developed  and  incorporated 
into  the  unit  operations  subsystem. 

The  results  of  this  work  are  the  specification  of  a  set 
of  models  to  be  developed  for  ASPEN.  They  are  discussed  in 
Section  4.2,2. 


: 


4.1.2.   SOLIDS  HANDLING 


A.   Software  Evaluated 

The  ASPEN  project  has  varying  amounts  of  information  on 
five  software  packages  designed  to  handle  solid  systems.   This 
software  has  been  developed  by  universities.   They  are  as 
follows: 
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1)  University  of  Pennsylvania  -  ASPEN 

These  programs  were  developed  for  ASPEN  by  the 
University  of  Pennsylvania  to  simulate  the  CO2  acceptor 
process  of  coal  gasification.   They  use  the  Plex  Data 
Management  System  (PDMS)  to  handle  the  complex  data 
structures  required  by  solid  streams.   This  is  a  dis- 
advantage in  that,  although  well  documented,  the  programs 
are  difficult  to  follow.   More  will  be  said  about  this 
software  package  in  a  later  section. 

2)  Control  Equipment  Design  and  Analysis  (C.E.D.A.) 
University  of  Houston 

C.E.D.A.  is  a  software  package  written  for  the 
Environmental  Protection  Agency  to  either  analyze  or  design 
equipment  dealing  with  particulate  air  pollution.   Economic 
modules  are  included  in  the  system.   A  FORTRAN  namelist 
input  format  is  used.   Stream  recycle  is  not  allowed. 
These  programs,  although  extensive,  are  poorly  documented 
and  error  laden.   It  is  being  used  primarily  as  a  reference 
for  standard  algorithms. 

3)  FORTRAN  Programs  for  the  Analysis  of  Grinding 
Processes,  University  of  Queensland 

This  is  a  limited  set  of  models  dealing  primarily  with 
communition.   They  were  developed  for  simulation  and 
control  of  mineral  treatment  processes.   The  programs  we 
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have  are  part  of  a  continuing  project  and  are  dated 
February,  1971.   A  new  breakage  function  has  been  developed 
for  later  models  and  should  be  evaluated  before  ASPEN 's 
crushing  modules  are  written. 
4)    Computer  Simulation  of  Coal  Preparation  Plants 

University  of  Pittsburgh 

This  is  a  comprehensive  simulator  dealing  with  coal 
preparation.   Recycle  is  allowed.   The  models  for  the 
crusher,  breaker  and  screen  were  done  under  a  subcontract. 
These  models  are,  perhaps,  the  most  comprehensive  available 
in  the  area  of  comminution. 


B.   Software  Developed 

As  mentioned  in  the  previous  section,  the  University  of 
Pennsylvania,  as  part  of  the  ASPEN  Project,  has  developed  a 
system  containing  the  necessary  modules  to  simulate  the  C02 
acceptor  process  of  coal  gasification.   It  was  developed  as  a 
tool  to  evaluate  the  effectiveness  of  the  plex  data  management 
system  (PDMS)  in  handling  complex  data  structures.   The  com- 
ponent modules  were  not  intended  to  serve  as  finished  programs 
for  the  ASPEN  system.   The  information  gained  from  this  proto- 
type was  a  key  factor  in  ASPEN' s  decision  to  isolate  the  unit 
operations  from  the  PDMS  structure.   By  doing  this  the  disad- 
vantage of  poor  readability  is  eliminated.   Although  the  com- 
ponent modules  are  unsuitable  as  written,  they  have  served  as 
the  basis  for  our  work  on  similar  modules. 
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C.   Complete  List  of  Solid  Handling  Operations, 

The  solid  handling  operations  which  are  likely  to  require 
modelling  are  as  follows: 

Cyclone  Separator 

Crusher 

Grinder 

Lift  Tubes 

Slurry  Pump 

Filter 

Screen/Classifier 

Centrifuge 

Drier 

Crystallizer 

Electrostatic  Precipitator 

Hydroclone 

Kiln  Drier 

Venturi  Scrubber 

Lock  Hopper 

Settler 

Flotation  Separator 

Thickener 
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D.   Basic  List  of  Solid  Handling  Operations 

This  list  represents  those  modules  which  are  most  critical 
to  modelling  an  operation  including  solids.   To  be  developed 
first  are  as  following: 

Cyclone  Separator 

Electrostatic  Precipitator 

Fabric  Filter 

Venturi  Scrubber 

Crusher 

Screen/Classifier 
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F.   Comparison  of  Available  Versus  Required  Models 


Required 

U  of 

U.  of 

U.  of 

models 

Penn 

C.E.D.A. 

Queensland 

Pittsburgh 

Crusher 

* 

* 

* 

Crystallizer 

Cyclone 

• 

* 

Centrifuge 

Dryer 

* 

Electrostatic 

Precipitator 

* 

Filter 

* 

Flotation  Separator 

* 

Grinder 

• 

* 

* 

Hydrocyclone 

* 

Kiln  Dryer 

Lift  Tubes 

Lock  Hopper 

Settler 

* 

Slurry  Pump 

Thickener 

Venturi  Scrubber 

• 

Screen 

* 

* 

■%, 
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4.1.3   ELECTROLYTE  SYSTEMS 


Electrolyte  systems  play  an  important  role  in  many  chemical 
processes.   Two  examples  are  the  Hot  Carbonate  Process  and  the 
Diethanolamine  Process  used  as  acid  gas  removal  processes  in 
coal  conversion  plants.   The  capability  of  ASPEN  will  be 
enhanced  significantly  if  ASPEN  can  simulate  unit  operations 
with  electrolyte  systems.   The  study  of  unit  operations  with 
electrolyte  systems  has  concentrated  on  two  aspects.   One  is 
how  to  handle  electrolyte  composition  characterization  so  that 
they  are  compatible  with  other  stream  systems.   The  other  is 
how  to  simulate  unit  operations  with  electrolyte  systems 
utilizing  conventional  unit  operation  routines.   The  Hot 
Carbonate  Process  and  the  Diethanolamine  Process  have  been 
chosen  as  the  benchmark  problems. 

In  the  past  year,  a  thorough  study  to  establish  a  rigorous 
thermodynamic  model  based  on  the  Pitzer's  equation  of  strong 
electrolyte  systems  has  been  carried  out.   Vapor-liquid  equi- 
librium data  of  the  CO2-K2CO3  aqueous  solution  used  in 
the  Hot  Carbonate  Process  has  been  correlated  successfully  with 
the  rigorous  model.   In  addition,  routes  to  calculate  enthalpy 
of  electrolyte  systems  have  been  set  up. 
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Based  on  the  established  thermodynamic  model,  a  study  on 
modelling  and  simulation  of  single  state  flash  was  undertaken. 
It  was  decided  that  electrolytes  and  molecular  species  but  not 
dissociated  ionic  species,  should  be  carried  along  in  process 
streams.   The  vapor-liquid  equilibrium  constants  of  non- 
volatile electrolytes  are  defined  to  be  zero.   In  cases  of 
reversible  chemical  processes,  a  pseudo  vapor-liquid  equilib- 
rium constant  K  is  defined,  for  each  volatile  species  involved 
in  chemical  reactions,  as  the  ratio  of  the  mole  fraction  of  the 
species  in  vapor  phase  to  that  in  liquid  phase  assuming  no 
chemical  change  occurs. 

By  doing  so,  existing  conventional  flash  routines  can  be 
used  for  reversible  chemical  processes  with  electrolytes. 
XFLASH,  a  general  purpose  vapor-liquid  flash  program  developed 
by  Dr's  Boston  and  Britt  of  the  ASPEN  Project,  has  been  used 
for  this  purpose  and  it  converges  without  difficulty  for  flash 
calculation  of  the  CO2-K2CO3  aqueous  solution  system. 

For  irreversible  chemical  processes,  an  extent  of  reaction 
term  has  to  be  incorporated  into  the  heat  and  mass  balance 
equations  of  the  flash  model.   Therefore,  more  extensive  study 
is  required. 


/}  v^-^i 
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4.1.4   CONVENTIONAL  REACTOR  MODELS 

This  task  was  completed  and  involved  the  specification  and 
development  of  conventional  reactor  models  not  present  in  FLOW- 
TRAN.   After  an  analysis  of  existing  simulators  and  the  antici- 
pated requirements  of  ASPEN  it  was  concluded  that  a  CSTR,  a 
plug  flow,  and  a  general  combustor  were  needed.   These  models 
were  developed,  coded,  and  tested  in  a  stand-alone  form  since 
at  the  time  of  the  work  there  was  no  simulator  environment 
available  (ASPEN  or  FLO^-TTRAN)  . 

CSTR  Model 

This  is  a  single  phase,  steady  state  model  with  the 
standard  assumption  of  no  spatial  variation  in  properties  or 
reaction  rate  throughout  the  vessel.   A  general  reversable 
power  law  rate  expression  is  used.   The  user  provides  the 
coefficients  of  this  rate  expression.   There  are  isothermal, 
adiabatic,  and  external  cooling  (heating)  options  available. 
A  Newton-Raphson  solution  technique  with  numerical  derivatives 
is  used. 


Plug  Flow  Model 

This  is  a  single  phase,  steady  state  model  with  the 
standard  assumptions  of  radial  uniformity  and  no  axial 
diffusion,  mixing,  or  heat  transfer.   The  same  power  law  rate 
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expression  used  in  the  CSTR  model  is  used  in  the  plug  flow 
model.   There  are  isothermal,  adiabatic,  and  external  heating 
(cooling)  options  available.   The  external  medium  may  flow 
co-current  or  countercurrent  to  the  process  fluid.   In  the 
later  case  the  outlet  external  medium  temperature  must  be 
specified.   The  model  cannot  solve  two  point  boundary  value 
problems.   There  are  also  several  pressure  drop  options 
available. 

Gear's  method  is  used  to  integrate  the  model  differential 
equations.   This  method  automatically  chooses  step-size  and  the 
order  of  the  integration  formula,  and  is  able  to  handle  the 
stiff  systems  which  occur  frequently  in  reactor  models. 

General  Combustor  Model 

This  is  a  very  simple  model  which  considers  the  adiabatic 
combustion  of  a  fuel  with  the  general  formula 


'aHbOcNaSe(ASH)f 


Thus  the  combustion  of  coal  or  oil,  as  well  as  pure  compounds, 
may  be  modelled.   Some  features  of  the  model  are: 

1.    Ash  may  be  included  in  the  fuel  and  is  treated  as 

inert.   It  enters  only  the  energy  balance  and  affects 

only  the  adiabatic  flame  temperature. 
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2.  Fraction  excess  air  is  specified. 

3.  The  distribution  of  fuel  nitrogen  between  NO  and  NO2 
is  specified  by  the  user. 

4.  A  specified  fraction  of  the  fuel  carbon  leaves  the 
combustor  as  char. 

This  later  feature  is  very  useful  in  modelling  coal  combustion. 

The  adiabatic  flame  temperature  is  determined  by  the  half 
interval  search  technique. 

4.1-5   UNIVERSITY  OF  PENNSYLVANIA  CO2  ACCEPTOR  MODELS 

The  following  models  were  developed  at  the  University  of 
Pennsylvania  using  the  Plex  Data  Management  System  (PDMS)  as 
part  of  the  CO2  acceptor  prototype  simulation.   The  details 
are  discussed  in  the  thesis  by  Jim  Neville  listed  in  Section  II 
as  an  ASPEN  publication. 


Crusher 

A  computer  program  has  been  prepared  to  simulate  a  crushing 
mill.   The  model  predicts  the  outlet  stream  particle  size  dis- 
tribution given  a  description  of  the  mill  and  the  inlet  stream 
distribution.   Mill  horsepower  requirement  is  calculated  from 
the  degree  of  size  reduction,  properties  of  the  solid,  and  the 
flow  rate.   A  schematic  of  the  crusher  with  variables  of  the 
model  is  shown  in  Figure  4.1.   In  the  figure,  q  is  solids  flow. 
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w  is  the  particle  size  distribution,  E.  is  the  Bond  Work 
Index,  E^  is  the  energy  requirement,  and  C,  S,  and  B  are  the 
mill  classification,  selection,  and  breakage  matrices,  res- 
pectively.  The  model  is  based  on  the  concept  of  a  milling 
circuit.   A  diagram  of  a  milling  circuit  is  shown  in  Figure 
4.2.   Here,  Q  refers  to  q.w  and  I  is  the  identity  matrix.    The 
milling  circuit  models  a  crushing  unit  as  the  combination  of  a 
mixer,  a  mill,  and  a  classifier.   The  feed  enters  the  unit 
where  it  is  mixed  with  oversized  recycle  from  the  classifier. 
This  combined  mill  feed  is  then  crushed  in  a  milling  section. 
The  mill  product  proceeds  to  a  classifier  where  the  larger 
sized  material  not  passing  unit  specifications  is  returned  to 
the  mill  feed.   All  streams  are  described  by  a  flow  rate  and 
a  particle  size  distribution.   The  mill  and  classifier  are 
represented  by  mathematical  functions  as  described  in  the 
thesis. 

In  the  model  implemented,  the  particle  size  distribution, 
milling  function,  and  classification  function  are  in  their 
discrete  forms.   That  is,  the  particle  size  distributions  are 
vectors  containing  weight  fractions  of  total  flow  for  discrete 
particle  diameter  ranges  while  the  milling  and  classification 
functions  are  square  matrices  with  dimensions  equal  to  the 
distributions.   A  continuous  function  would  provide  a  more 
accurate  description  of  the  particle  size  distribution  but  the 
discrete  form  appears  to  be  more  convenient  and  more  widely 
used  for  computer  implementation. 
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Hot  Gas  Swept  Hammer  Mill 

A  program  to  simulate  a  hot  gas  swept  coal  hammer  mill 
has  been  prepared.   Given  conditions  of  the  inlet  stream,  a 
description  of  the  mill  and  the  solids  residence  time,  the 
module  predicts  conditions  of  the  outlet  stream,  power  require- 
ment, and  dimensions  of  the  drying  duct. 

Figure  4.3  shows  a  schematic  of  the  mill.   Solids  enter  the 
crushing  section  where  they  are  fractured  by  the  impact  of 
spinning  hammers.   The  crushed  solids  are  classified  and  the 
product  is  swept  out  of  the  drying  duct  by  a  hot  gas  stream. 

Cyclone 

A  computer  program  to  design  and  simulate  a  cyclone  par- 
ticle collector  has  been  prepared.   The  design  is  based  on  a 
specification  of  the  cyclone  body  diameter.   Given  this  dimen- 
sion and  a  description  of  the  inlet  stream,  the  collection 
efficiency,  outlet  particle  size  distributions,  flow  rates,  and 
pressure  drop  are  predicted.   The  important  variables  and 
parameters  are  presented  in  Figure  4.4.   In  the  figure,  n  is 
the  collection  efficiency  and  D^,  b^,  H^,  S^,  Dg, 

^Q,    Z^,  and  J(.   are  cyclone  dimensions.   The  feed  enters 
the  cyclone  through  a  tangential  duct.   As  the  gas  and  solids 
spiral  down  through  the  cyclone,  solids  are  forced  to  the  walls 
and  fall  through  the  dipleg.   The  tapered  cyclone  body  causes 
the  gas  (as  well  as  some  of  the  finer  solids)  to  exit  through 
the  upper  outlet. 
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The  model  predicts  the  dimensions  of  the  cyclone,  its 
collection  efficiencies,  and  its  pressure  drop.   Although  the 
temperature  in  cyclones  is  uniform,  new  enthalpies  are  calcu- 
lated for  the  outlet  streams  due  to  pressure  drop  and  redis- 
tribution of  solids. 

The  complete  cyclone  is  designed  given  the  user's  speci- 
fication of  the  body  diameter,  which  affects  both  the  collec- 
tion efficiency  and  pressure  drop. 

The  collection  efficiency  is  predicted  for  each  particle 
size  using  the  method  of  Leith  and  Licht  which  combines  descip- 
tions  of  particle  motion  and  gas  flow. 


Furnace 

A  program  to  simulate  a  coal  furnace  has  been  prepared. 
Given  conditions  of  air  and  coal  streams  and  characteristics  of 
insulation,  conditions  of  flue  gas  and  ash  are  predicted.   The 
heat  duty  and  heat  loss  are  also  calculated. 

A  schematic  of  the  furnace  showing  important  variables  is 
presented  in  Figure  4.5.   Coal  is  completely  burned  in  excess 
air,  producing  ash  and  flue  gas,  which  exit  at  the  furnace 
temperature.   The  product  of  the  overall  heat  transfer  coeffi- 
cient and  surface  area  and  the  ambient  temperature  must  be 
specified  to  permit  calculation  of  the  heat  loss. 
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The  furnace  model  involves  atom  balances  for  each  element, 
the  energy  balance,  and  a  heat  transfer  equation  to  compute 
heat  loss.   Complete  combustion  of  the  coal  to  carbon  dioxide, 
water,  and  sulfur  dioxide  is  assumed.   Oxygen  in  the  coal  is 
used  for  combustion  and  nitrogen  becomes  nitrogen  gas.   Under- 
lying assumptions  are  that  air  is  in  excess,  and  negligible 
amounts  of  carbon  monoxide  and  hydrogen  are  produced.   A  heat 
duty  is  estimated  from  the  lower  heat  of  combustion  of  coal. 

The  solution  procedure  consists  of  solving  the  mass  and 
energy  balances  using  the  Newton-Raphson  technique.   When  the 
calculations  are  converged,  the  heat  duty  is  calculated. 

4.1.6   GENERAL  PHASE  AND  CHEMICAL  EQUILIBRIUM 


This  project  is  subcontracted  to  the  University  of  Penn- 
sylvania.  Its  purpose  is  to  provide  a  comprehensive  general 
equilibrium  capability  that  will  be  able  to  handle  multiple 
phases  in  phase  and  chemical  equilbrium,  including  solid 
phases.   Important  special  cases  are  gas  phase  chemical  equi- 
librium and  multiple  phase  phase  equilbrium. 

The  free  energy  minimization  formulation  of  the  equilibrium 
criteria  has  been  used.   This  formulation  results  in  a  mathe- 
matical programming  problem.   Four  programs  have  been  developed 
based  on  four  different  minimization  techniques.   Testing  has 
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shown  two  of  these  algorithms  to  be  superior,  the  Rand  method 
and  the  Gradient  Projection  method.   Both  of  these  are  Newton 
type  methods  but  the  constraint  equations  are  handled  differ- 
ently.  One  or  both  of  these  successful  programs  will  be  incor- 
porated into  ASPEN. 

One  difficulty  associated  with  using  a  free  energy  minim- 
ization algorithm  to  solve  multiple  phase  phase  equilibrium 
problems  is  the  determination  of  the  correct  number  of  phases. 
If  a  solution  exists  containing,  say,  n  phases,  it  is  always 
possible  to  find  a  mathematical  solution  consisting  of  n-1 
phases  that  represents  a  local  minimum  of  the  system  free 
energy.   When  such  a  solution  is  found,  it  is  necessary  to 
initiate  a  search  in  a  region  such  that  the  algorithm  will  tend 
to  converge  to  the  n  phase  solution,  which  represents  a  lower 
minimum  in  the  system  free  energy.   The  algorithms  developed  in 
this  project  employ  a  heuristic  approach  to  handle  this  problem. 

4.2   WORK  FORECAST 


Since  system  design  has  been  substantially  completed, 
future  work  will  involve: 

1.  coding  of  system  programs 

2.  coding  of  unit  operations  models  currently  specified 

3.  modification  of  acquired  models 

4.  specification  and  coding  of  new  models. 
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Work  during  the  next  quarter  will  concentrate  on  the  first 
three  of  these  areas  and  will  establish  the  ASPEN  basic  sys- 
tem.  During  the  remainder  of  the  project  new  models  will  be 
specified  and  coded  as  required  for  the  benchmark  simulations. 

4.2.1  SYSTEMS  PROGRAMS 

Common  functions,  needed  by  many  or  all  unit  operations 
models,  will  be  isolated  and  coded  as  UOS  "utility"  sub- 
routines.  These  common  functions  include  stream  bead  locating 
and  unlocking,  stream  interpreter  functions,  stream  addition 
and  copying,  error  handling  for  common  errors,  component  list 
packing,  and  common  diagnostic  output  to  the  history  file. 
These  utilities  are  discussed  in  Chapter  9  of  the  Design  Report, 

Most  of  these  subroutines  have  been  specified  and  are  ready 
for  coding.   Others  will  be  identified  as  coding  of  the  unit 
operation  models  proceeds.   These  subroutines  will,  of  neces- 
sity, be  coded  on  a  priority  basis.   They  should  be  substan- 
tially completed  next  quarter. 

4.2.2  COAL  REACTORS 


The  following  simple  models  will  become  part  of  the  basic 
system: 
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1.  A  yield-based  model 

2.  An  extent-based  model 

3.  Fractional  conversion  model 

4.  A  stoichiometric  reactor  model  which  allows  a 
mix  of  equilibrium  and  other  specifications 

5.  A  stirred  tank  reactor  model 

6.  A  plug  flow  reactor  model 

a.  Cocurrent  flow  (initial  value  problem) 

b.  Counter  current  flow  (2  point  boundary  value 
problem) . 

Review  of  available  coal  conversion  models  has  revealed  that 
a  yield-based  model  may  prove  particularly  useful  in  the 
modelling  of  coal  devolatilization  and  liquefaction.   Stirred 
tank  and  plug  flow  reactor  models  have  demonstrated  utility  in 
the  simulation  of  coal  combustion  and  gasification  processes. 
It  is  expected  that  model  (4)  above  will  find  general  useful- 
ness since  coal  conversion  processes  often  involve  the  combina- 
tion of  reactions  at  equilibrium,  reactions  proceeding  to 
completion,  and  reactions  far  from  equilibrium. 

Model  specification  are  currently  being  written  and  solu- 
tion algorithms  researched.   Coding  of  the  above  models  will 
begin  during  the  next  quarter  and  be  completed  the  following 
quarter. 
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4.1.3   SOLIDS  HANDLING 


The  following  models  will  be  developed  as  part  of  the  basic 
system. 

A.  CYCLONE  -  Scheduled  completion  6/16/78 

This  capability  can  be  used  to  analyze  or  design 
tangential  inlet  cyclone  particle  collectors.   Two 
algorithms  are  available  to  calculate  efficiency.   All 
variables  may  be  defaulted  except  the  diameter  in  the 
analysis  mode  or  required  efficiency  in  design  the  mode. 
Either  high  or  medium  efficiency  cyclones  may  be 
specified.   Multiple  cyclones  in  parallel  may  be  either 
analyzed  or  designed. 

B.  ELECTROSTATIC  PRECIPITATOR  -  Scheduled  completion  6/30/78 

This  capability  can  be  used  to  analyse  or  design 
rectangular  duct  electrostatic  precipitators.   Multiple 
electroststic  precipitators  in  parallel  are  automatically 
designed  to  meet  the  required  efficiency  in  design  mode. 
D.   VENTURI  SCRUBBER 

This  capability  can  be  used  to  either  design  or 
analyze  venturi  scrubbers.   In  design  mode,  the  maximum 
size  of  the  venturi  scrubber  and  the  maximum  gas  flow 
rate  are  specified  by  the  user.   Multiple  scrubbers  are 
specified  automatically  when  the  maxima  are  exceded. 
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E.  CRUSHER 

This  capability  can  simulate  continuous  grinding 
systems.   It  can  be  used  to  predict  the  size  distributions 
produced  by  various  types  of  crushers  and  mills.   It  is 
assumed  that  nothing  happens  to  the  solid  except  for  the 
size  reduction.   No  moisture  is  lost.   Bond  law  is  used  to 
predict  the  energy  requirement.   Defaults  are  supplied  for 
the  various  mill  matrices. 

F.  SCREEN/CLASSIFIER  -  COMPLETION  DATE  3/26/78 

This  capability  can  be  used  to  model  classification 
of  solid  particles  by  screening.   Either  single  or  multiple 
screens  may  be  specified.   This  model  is  designed  to  be 
used  in  conjunction  with  the  crusher  model. 

4.2.4   ELECTROLYTE  SYSTEMS 


The  plan  is  to  develop  routines  capable  of  simulating 
single-stage  flash,  multistage  flash  and  continuous  contacting 
packed-bed  absorption  of  electrolyte  systems  taking  advantages 
of  existing  software.   Necessary  modification  of  the  existing 
routines  will  be  identified  and  carried  out  for  single-stage 
flash  and  multistage  absorption.   Because  both  of  the  two 
benchmark  problems  are  reversible  chemical  processes,  a  pseudo- 
K  approach  alone  should  serve  the  purpose.   Models  with  the 
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extent  of  reaction  term  will  not  be  implemented.   It  is 
believed  that  continuous-contacting  packed  bed  absorption 
routine  for  electrolyte  systems  will  be  a  more  complicated 
problem  and  demand  a  significant  amount  of  effort. 

This  capability  will  not  be  part  of  the  basic  system  since 
further  research  is  required  before  models  can  be  specified. 

4.2.5  CONVENTIONAL  REACTOR  MODELS 

Although  this  task  is  complete  some  work  will  be  required 
to  convert  the  stand-alone  reactor  programs  into  ASPEN  models. 
The  work  required  will  be  similar  to  that  discussed  for  FLOW- 
TRAN  models.   The  plug  flow  and  CSTR  models  will  probably  be 
incorporated  into  the  coal  reactor  models. 

4.2.6  GENERAL  PHASE  AND  CHEMICAL  EQUILIBRIUM 


Future  work  in  this  project  will  involve  the  addition  of 
features  to  the  present  programs  and  the  development  of  an 
alternate  approach  based  on  the  Chien  and  Sanderson  method. 
The  objective  is  to  be  able  to  model  systems  based  on  an 
approach  to  equilibrium  rather  than  absolute  equilibrium  and 
to  be  able  to  handle  as  constraints  reactions  of  known  extent. 
This  modified  equilibrium  capability  will  be  very  useful  in 
modelling  coal  gasification. 
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4.2.7   FLOWTRAN  CONVERSION 

Many  of  the  FLOWTRAN  blocks  will  be  converted  into  ASPEN 
models.   These  conversions  will  involve  the  following  types  of 
modification. 


1-   Physical  Property  Subroutine  Calls 

The  calls  to  FLOWTRAN  physical  property  subroutines  must  be 
replaced  by  calls  to  ASPEN  physical  property  subroutines.   This 
replacement  will  be  straightforward  and  systematic. 
2.   Retention  and  Convergence 

The  ASPEN  system  puts  more  emphasis  on  saving  results  from 
pass  to  pass  then  does  FLOWTRAN.   The  ASPEN  philosophy  is  that 
the  iteration  variables  of  a  model  should  be  stored  in  the 
block  data  list  of  a  block  at  the  completion  of  a  pass,  and 
that  calculations  should  be  restarted  from  these  values  on 
the  next  pass.   In  other  words  the  data  structure  of  ASPEN  is 
thought  of  as  including  all  the  system  iteration  variables, 
stream  and  block  internal.   The  function  of  a  block  model  is  to 
converge  some  partition  of  the  full  set  of  system  equations. 
Under  this  concept  model  initialization  calculations  are  done 
only  the  first  pass  of  a  model.   On  subsequent  passes  the  model 
iterations  are  simply  restarted  from  the  previous  solution. 
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a. 

b. 
c. 


The  consequences  of  this  concept  are  that  during  FLOWTRAN 
to  ASPEN  conversion: 

iteration  variables  must  be  moved  from  local  storage 
to  the  retention  area  of  the  block  data  list, 
initialization  calculations  must  be  bypassed, 
numerical  procedures  involving  arbitrary  first  steps, 
etc.  must  be  modified  or  replaced. 

3.  Calculation  Control 

ASPEN  has  two  calculation  control  flags,  called  Energy 
Balance  and  Results.   The  Results  flag  controls  the  calculation 
of  model  results  not  normally  needed  for  convergence  of  the 
Heat  and  Material  Balance.   They  are  calculated  during  a 
Results  Pass.   This  flag  is  somewhat  similar  to  the  FLOWTRAN 
KOUT  control  variable.   The  Energy  Balance  flag  is  used  to 
control  the  calculation  of  outlet  stream  entalpy  when  this 
calculation  is  optional.   This  flag  is  used  in  conjunction 
with  simple  (mixer,  splitter,  etc.)  models  to  provide  a  "mass 
balance  only"  capability.   The  FLOWTRAN  blocks  must  be  modified 
so  that  calculation  control  is  based  on  these  two  flags. 

4 .  History  and  Report 

In  ASPEN  the  unit  operations  models  themselves  will  not 
write  the  final  report  as  n  FLOWTRAN,  so  those  WRITE  statements 
will  have  to  be  removed  from  the  FLOWTRAN  blocks.   On  the  other 
hand,  ASPEN  has  a  diagnostic  level  which  controls  the  amount  of 
output  to  the  history  file.   Depending  on  the  level  set  by  the 


201 


user  an  ASPEN  model  may  write  more  or  less  informaton  than  the 
FLOWTRAN  block.   FLOWTRAN  blocks  will  require  modification  to 
accomodate  this  feature. 

5.  Inert  Solids  and  Entrainment 

Conventional  type  vapor-liquid  models  in  ASPEN  will  be  able 
to  handle  solids  as  inerts.   Inert  solids  will  enter  energy 
balance  but  not  phase  equilibrium  calculations.   The  user  will 
be  able  to  specify  the  fraction  of  inert  solids  going  to  a 
given  outlet  stream.   This  feature  must  be  added  to  FLOWTRAN 
flash,  distilltion,  etc.  blocks.   A  similar  "add  on"  feature 
planned  for  ASPEN  flash  blocks  is  for  the  user  to  be  able  to 
specify  that  a  fraction  of  the  liquid  goes  overhead  with  the 
vapor  as  an  entrained  fluid. 

6.  Interface 

The  ASPEN  model  interface  with  the  main  calling  program  is 
different  than  FLOWTRAN' s.   Basically,  an  additional  interface 
routine,  which  we  call  model$,  must  be  written  for  each  model. 
Different  system  labelled  commons,  etc.  are  also  involved  in 
the  interface  modifications. 

7 .  Dimensional  Constraints 

The  dimensional  constraints  on  number  of  components,  number 
of  trays,  etc.  in  FLOWTRAN  will  be  removed. 

8 .  Documentation 

The  models  will  be  documented  according  to  ASPEN  stan- 
dards.  This  involves  both  comments  and  technical  description. 
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None  of  the  above  modifications,  by  themselves,  are  a  major 
task.   Taken  together,  however,  a  substantial  amount  of  effort 
is  required.   Therefore  not  all  models  can  be  included  in  the 
basic  system.   The  following  FLOWTRAN  unit  operation  models 
will  be  converted  for  the  basic  system. 

Two  phase  flash  (MFLSH) 

Three  phase  flash  (KFLSH) 

Rigorous  distillation  (FRAKB) 

Shortcut  distillation  (DISTL  DSTWU) 

Rigorous  absorber  (ABSBR) 

Liquid-Liquid  extraction  (EXTRC) 

Compressor/turbine  (GCOMP) 

Centrifugal  pump  (PUMP) 

Reactor  (XTNT) 

Heat  exchanger  (all  models) 

4.2.8   OTHER  MODELS 


Mixer-Splitter 

The  FLOWTRAN  simple  mixer/splitter  blocks  (SEPR,  ADD,  MIX, 
SPLIT,   PART)  were  not  included  in  the  list  or  the  previous 
section  since  the  conversion  of  these  blocks  would  involve 
almost  a  complete  rewrite.   They  will  serve,  however,  as  the 
basis  for  the  ASPEN  mixer/splitters.   The  ASPEN  basic  system 
will  have  a  mixer,  a  make-up  mixer,  a  stream  splitter,  a  phase 
splitter,  and  a  component  splitter. 
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Flash 

The  two  and  three  phase  flash  algorithms  developed  by  Dr. 

Joe  Boston  of  the  ASPEN  staff  will  be  made  available  to  the 

project  at  no  cost.   They  will  be  treated  as  optional  methods 

with  FLOWTRANS's  MFLSH  and  KFLSH  being  the  alternate  options. 

The  two  phase  algorithm  will  also  be  used  as  part  of  the 

electrolyte  work  discussed  earlier. 

Distillation 

It  is  planned  to  purchase  two  distillation  programs  with 

state-of-the-art  capabilities.   These  will,  of  course,  be  con- 

verted into  ASPEN  models  -  See  Task  7  for  further  discussion. 

General  Equilibrium 

The  programs  currently  being  developed  at  the  University  of 

Pennsylvania  and  discussed  in  Section  4.1.6  will  be  incorpor- 

ated into  ASPEN  as  a  general  multi-phase  and  chemical  equilib- 

rium capability. 
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TASK  5:   DEVELOPMENT  OF  COST  ESTIMATION  AND  ECONOMIC 
EVALUATION  SUBSYSTEM 

5.1   WORK  ACCOMPLISHED 

Work  on  the  Cost  Estimation  and  Economic  Evaluation 
Subsystem  has  concentrated  on  functional  specifications  and 
system  design.   The  functional  specifications  were  updated 
after  receiving  recommendations  from  the  Advisory  Committee. 
The  system  design  for  the  basic  system  has  been  carried  out 
according  to  the  functional  specifications.   In  addition,  study 
on  sizing  and  costing  methods  for  major  process  equipment  has 
been  done  including  literature  survey  and  computer  program 
evaluations.   Moreover,  cost  estimation  methods  for  capital 
investment  and  economic  evaluation  methods  have  also  been 
analyzed.   Guthrie's  Modular  method  and  Hackney's  Equipment 
Ratio  method  were  selected  for  use  in  ASPEN. 


5.1.1   SYSTEM  DESIGN 

The  objective  of  system  design  for  the  Cost  Estimation 
and  Economic  Evaluation  Subsystem  was  to  define  the  program 
interfaces  and  data  structures.   In  order  to  define  the  program 
structure,  information  flows  about  the  subsystem  have  been 
analyzed  and  constructed  for  a  top  level  design.   Also 
information  flows  for  the  basic  structure  charts,  which 
indicate  required  information  for  each  module,  have  been 
defined. 
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The  data  structures  have  been  developed  for  each  sizing 
and  costing  block  and  also  economic  evaluation  blocks  such  as 
capital  investment  estimation,  operating  cost  estimation  and 
profitability  analysis  blocks.   The  sensitivity  analysis  func- 
tion will  not  be  included  in  the  CES  subsystem.   It  will  be 
included  in  the  Executive  program  because  of  the  wide  variety 
of  its  usage  for  other  ASPEN  subsystems. 

System  design  for  this  subsystem  can  be  divided  into  the 
design  of  sizing  and  costing  blocks  and  economic  evaluation 
block.   The  sizing  and  costing  blocks  correspond  to  the  flow- 
sheet information  and  input  data  can  be  specified  according  to 
the  flowsheet.   The  system  should  be  designed  to  have  flexibil- 
ity to  deal  with  various  information.   The  user  can  start  with 
either  sizing  or  costing  and  specify  material  balance  data, 
sizing  results  or  costing  results  if  so  required.   If  he  speci- 
fies the  corresponding  material  and  heat  balance  HMB  block 
identifier,  the  required  data  may  be  retrieved  for  sizing  and 
costing  from  the  HMB  block.   In  addition,  he  can  also  specify 
the  stream  identifier  to  retrieve  the  stream  data  for  special 
equipment  such  as  pumps.   The  data  structure  of  sizing  and 
costing  blocks  is  based  on  the  data  structure  so  that  it  may 
have  the  flexibility  to  handle  variable  length  data.   However, 
it  is  relatively  hard  to  use  the  directly.   To  avoid  the  com- 


206 

plexity,  two  levels  of  structure,  which  consist  of  a  model 
interface  program  and  an  actual  model  program  for  individual 
sizing  and  costing  block,  are  used.   The  details  are  described 
the  Design  Report. 

The  economic  evaluation  modules  consist  of  four  modules: 
the  utility  summary  calculation  module,  the  capital  investment 
estimate  module,  the  operating  cost  estimate  module,  and  the 
economic  and  profitability  analysis  module.   However,  there  is 
only  one  interface  program  which  retrieve  required  data  from 
the  plex  and  call  the  programs  above  mentioned.   The  data 
structure  of  the  economic  evaluation  block  consists  of  data 
for  each  plant  section.   The  plant  section  data  include  cost 
estimation  factors  used  for  capital  investment  estimates,  cost 
data  for  package  units  and  utility  requirement  data. 

^ • ^ • 2 •   DESIGN  OF  SIZING  AND  COSTING  MODULES  PROGRAM  STRUCTURE 


ASPEN  may  provide  sizing  and  costing  models  for  various 
kinds  of  equipment.   Each  model  program  consists  of  a  pair  of 
model  interface  programs  and  actual  model  programs.   As  all  the 
information  required  for  sizing  and  costing  models  is  stored  in 
the  plex  storage,  the  model  interface  programs  may  be  used  to 
retrieve  data  from  the  plex  storage  and  to  break  down  block 
data  into  more  useful  arrays  for  the  actual  model  programs.   In 
addition,  the  corresponding  unit  operation  block  or  stream  bead 
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may  be  located  and  also  may  be  broken  down  into  several  arrays 
because  the  corresponding  data  are  required  for  costing  and 
sizing.   Therefore,  actual  model  programs  are  completely  iso- 
lated from  the  PLEX  data  storage  so  that  it  is  much  easier  to 
write  and  maintain  programs.   Standard  model  interface  programs 
will  be  provided.   Furthermore,  the  user  may  supply  his  own 
programs  as  actual  model  programs.   In  this  case,  the  standard 
model  interface  program  (CUSER$)  will  be  used  by  supplying  the 
external  name  of  the  program  in  the  argument  list. 

Sizing  and  costing  models  may  be  allowed  to  start  with 
sizing  or  costing  and  end  with  sizing  or  costing.   Another 
calculation  option  is  just  to  specify  size  and  cost  data  and  to 
store  this  data.   This  means  that  the  user  can  specify  his  own 
size  data  calculated  by  other  methods  to  run  the  costing  model 
and  also  give  his  cost  data. 


DATA  STRUCTURE 

All  the  sizing  and  costing  data  are  stored  in  the  plex 

storage.   The  data  structure  of  sizing  and  costing  blocks  are 

basically  the  same  as  that  of  unit  operation  blocks.   In  the 

sizing  and  costing  block,  a  pointer  for  the  corresponding  unit 

operation  block  on  stream  bead  is  included  so  that  the  sizing 
and  costing  block  can  retrieve  data  from  the  corresponding  bead 
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Another  kind  of  pointer  is  used  for  utility  block  data. 
The  utility  block  data  include  utility  type,  utility  properties 
such  as  temperature,  heat  of  combustion  etc.  and  unit  cost 
information.   More  than  one  utility  may  be  allowed  to  be  used 
in  the  model  program.   Utility  data  may  also  be  treated  as 
stream  data.   In  this  case,  such  stream  flowrates  and  condi- 
tions should  be  calculated  in  the  heat  and  material  balance 
section.   Utility  summary  calculations  do  not  include  the 
stream  data  which  have  already  been  balanced.   Therefore,  in 
order  to  estimate  plant  operating  cost,  those  streams  for 
utilities  may  be  assumed  as  raw  materials. 

5.2.3   DESIGN  OF  ECONOMIC  EVALUATION  MODULE  PROGRAM  STRUCTURE 


There  is  only  one  economic  evaluation  model  interface 
program  which  may  control,  retrieve  or  locate  data  from  four 
actual  model  programs  such  as  the  utility  summary  calculation 
program,  the  capital  investment  program,  the  operating  cost 
program  and  economic  analysis  program.   Those  programs  need  to 
be  isolated  from  the  plex  storage  as  much  as  possible  so  they 
are  easier  to  write,  read  and  maintain. 

For  capital  estimates,  there  are  two  methods  provided, 
namely,  Guthrie's  modular  method  and  Hackney's  equipment  ratio 
method  and  the  user  can  choose  the  method.   In  addition  to 
that,  the  user  may  specify  his  own  factors  for  different  plant 


209 

sections.   If  he  doesn't  specify  factors,  the  default  values 
that  depend  on  the  estimation  method  will  be  supplied.   The 
default  values  are  taken  from  Guthrie's  or  Hackney's  recommend- 
able  values  in  their  articles.   Moreover,  if  the  user  wants  to 
write  his  own  module  for  the  capital  investment  estimate,  the 
argument  list  of  his  program  should  meet  the  requirements  given 
by  the  specification.   User's  supplied  programs  for  operating 
cost  estimates  and  economic  evaluation  or  analysis  should  meet 
the  same  requirements. 

Operating  cost  may  be  estimated,  on  the  basis  of  capital 
investment,  raw  material,  by  product  and  utility  costs. 


DATA  STURUCTURE 

Only  one  economic  evaluation  block  exists  during  a  simula- 
tion and  this  includes  the  capital  investment  data,  operating 
cost  data  and  economic  evaluation  or  analysis  data.  However, 
all  the  output  results  are  not  stored  in  the  economic  evalua- 
tion block  but  printed  out.  Some  of  the  output  results  which 
can  be  called  retention  parameters  are  stored  in  the  block  for 
sensitivity  studies. 

The  economic  evaluation  block  involves  pointers  for  plant 
section  blocks  which  are  used  to  etimate  capital  investment  of 
process  plants.   The  plant  section  blocks  include  a  set  of  cost 
estimation  factors  which  depend  on  the  estimation  method.   A 
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plant  section  is  defined  as  a  set  of  equipment  involved  in  the 
plant  and  specified  by  the  user's  input.   It  is  still  possible 
to  define  a  plant  section  for  only  one  piece  of  equipment  or 
the  total  plant.   The  reason  why  plant  section  blocks  are 
required  is  to  increase  accuracy  of  estimates. 

The  plant  section  block  has  pointers  to  sizing  and  costing 
blocks  which  are  included  in  the  section  and  also  involve 
factors  for  cost  estimates  and  utility  summary  data.   There- 
fore, the  economic  evaluation  model  interface  program  can 
retrieve  sizing  and  costing  block  data. 

5.2.4   COST  DATA  FILE 


All  cost  data  which  are  required  for  sizing  and  costing 
models  are  stored  on  the  cost  data  file.   The  cost  data  file 
may  also  include  cost  data  and  sets  of  factors  for  economic 
evaluation  model.   Two  kinds  of  cost  data  files  are  provided; 
one  is  the  system  cost  data  file  and  the  other  is  the  user's 
file.   Ths  user  can  create  and  access  his  own  cost  data  file 
which  are  generated  by  copying  from  the  system  cost  data  file 
and  adding  his  cost  data  to  the  file.   The  user  may  not  add 
data  to  the  system  cost  data  file.   If  the  user  wants  to 
override  data  from  the  cost  data  file,  he  can  specify  these  as 
the  inout  data. 
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5.3   WORK  FORECAST 


During  the  next  quarter,  the  system  design  and  coding  of 
the  basic  cost  esimation  and  economic  evaluation  subsystem  will 
be  completed  and  tested.   The  list  of  input  parameters  and 
retention  parameters  for  individual  sizing  and  costing  block 
will  be  completed  and  also  updated  as  more  information  becomes 
available. 

Moreover,  decisions  will  be  made  as  to  which  program  from 
PEPCOST  and  PROVES  needs  to  be  aquired  for  the  basic  system. 
Study  on  sizing  and  costing  methods  for  various  process 
equipment  and  economic  evaluation  methods  will  be  completed. 
Current  cost  data  for  the  cost  data  file  will  be  collected  and 
also  updated  as  more  information  and  current  data  becomes 
available. 
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TASK  6   DATA  REGRESSION  SUBSYSTEM 

6.1  WORK  ACCOMPLISHED 

In  a  study  of  data  regression  methods,  three  nonlinear 
regression  programs  were  evaluated.   They  were  a  Harwell 
Library  routine,  a  program  based  on  the  Law  and  Farris 
transformational  discrimination  algorithm,  and  a  program 
developed  by  H.  I.  Britt.   Several  test  problems  were 
constructed  for  these  programs.   In  all  test  cases,  the 
performance  of  all  three  programs  was  acceptable,  with  no 
single  one  showing  clear  superiority  over  the  other  two. 
Additional  details  are  given  in  the  Seventh  QPR. 

6 . 2  WORK  FORECAST 


Camparison  of  the  FLOWTRAN  regression  algorithm  with  the 
three  algorithms  already  tested,  orignally  planned  for  last 
quarter,  has  been  postponed  until  the  next  quarter. 

Most  of  the  next  quarter  will  be  devoted  to  implementing 
the  basic  version  of  the  Data  Regression  Subsystem.   A  modi- 
fication of  the  VLE  program  of  FLOWTRAN  will  be  used  for 
this.   The  modifications  will  be  mainly  to  make  the  input  and 
output  compatible  with  ASPEN.   Regression  variable,  parameter 
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value  and  component  specifications  will  be  keyed  on  property 
and  component  names  in  the  same  way  as  the  input  to  the  Data 
File  Management  System  (DFMS) .   Parameter  value  input  state- 
ments will  have  a  form  similar  to  those  of  the  DFMS.   The 
regression  results  will  be  stored  on  a  Type  2  data  file 
that  may  be  accessed  by  the  DFMS,  or  from  which  data  may  be 
retrieved  by  the  simulation  Input  Processor.   The  forms  of  the 
raw  data  input  statements  will  not  be  changed  from  the  present 
forms  in  the  VLE  program. 
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TASK  7:   ACQUISITION  OF  PROPRIETARY  SOFTWARE  AND  MODIFICATION 
FOR  USE  IN  ASPEN 

The  objective  of  this  task  is  to  identify,  evaluate, 
acquire,  and  modify  software  for  inclusion  in  the  ASPEN 
system.   The  software  acquistion  has  been  divided  into  two 
parallel  tasks.   The  first  one  was  directed  at  the  acquisition 
of  a  base  simulator  early  in  the  project  in  order  to  assure 
that  ASPEN  will  start  with  the  current  technology  in  process 
sinulation.   The  second  task  concerned  an  extensive  search  in 
order  to  identify  modules  that  may  be  incorporated  into  ASPEN. 

7.1   WORK  ACCOMPLISHED 

7.1.1   ACQUISITION  OF  A  BASE  SIMULATOR 

After  considerable  investigation  and  negotiation,  Mon- 
santo 's  process  simulator  FLOWTRAN,  was  selected  to  serve  as 
the  base  simulator.   FLOWTRAN  was  installed  by  Monsanto  at 
M.I.T. 's  computing  center  on  February  27,  1978.   Acceptance 
tests  have  been  carried  out  successfully. 

It  is  estimated  that  the  conversion  of  FLOWTRAN  modules  to 
run  under  ASPEN  executive  will  be  completed  by  the  end  of 
September,  1978. 


■/.  ^ti  ■ 
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7.1.2   IDENTIFICATION 

OF  EXISTING  SOFTWARE 

The  base  simulator 

,  FLOWTRAN,  provides  ASPEN  with  a  minimal 

set  of  modules.   There 

are  still  a  number  of  modules  that  are 

necessary  to  complete 

the  system.   The  objective  of 

this  sub- 

task  is  to  identify  if 

such  modules  already  exist. 

If  they  do 

exist,  then  a  "make"  or  "buy"  decision  must  be  made. 

In  this 

case  the  "make"  means 

to  develop  the  modules  by  pro: 

ject 

personnel. 

The  four  phases  of 

work  required  to  acquire  and 

install 

existing  programs  into 

ASPEN  system  are: 

1.   Survey:   Enough  in 

formation  must  be  obtained  about  each 

program  to  permit  as  complete  and  accurate  an  evaluation 
as  possible. 

2.  Evaluation:   The  evaluation  phase  provides  an  objective 
review  and  comparison  of  the  advantages  and  disadvantages 
of  all  programs  being  condiered  for  acquisition. 

3.  Procurement:   Limited  funds  are  available  to  assist  in 
obtaining  programs  desired  for  use  in  ASPEN.   These  must  be 
allocated  in  an  optimal  way  so  as  to  satisfy  the 
requirements  of  ASPEN. 

4.  Modification:   All  the  programs  purchased  will  require 
some  modification.   These  modifications  will  have  been 
identified  before  purchasing  the  programs.   Since  con- 
siderable effort  is  involved  in  program  modification,  the 
amount  of  modification  required  is  an  important  criteria 
for  selection  of  programs. 
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The  project  staff  has  prepared  a  report,  "A  List  of  Com- 
puter Programs  for  Chemical  Engineers",  to  report  the  final 
result  of  the  software  survey  and  to  assess  the  state-of-the- 
art  in  software  for  flow-sheet  analysis.   This  report  has  been 
sent  to  the  software  survey  contributors  and  to  Chemical 
Engineering  for  inclusion  in  their  next  survey.   Only  the 
programs  in  public  domain  are  included  in  the  report. 

7.1.3   DISTILLATION  PROGRAMS 


A  comparison  of  computer  programs  for  distillation  calcu- 
lations suitable  for  ASPEN  was  made.   Evaluation  of  programs 
was  carried  out  by  running  test  problems  of  widely  different 
characteristics.   The  objective  was  to  detect  conditions  under 
which  a  particular  program  will  behave  well  or  will  fail. 

Some  programs  can  solve  directly  for  design  specifications, 
while  others  require  a  trial  and  error  procedure  by  the  user. 
In  order  to  evaluate  common  characteristics  of  all  programs,  it 
was  decided  to  construct  test  examples  of  the  rating  type.   For 
a  distillation  column,  this  typically  means  specifying  the 
reflux  rate  and  the  amount  of  the  bottom  (or  top)  product. 

Test  problems  are  described  in  the  Appendix  B.   Test 
results  and  the  final  conclusions  are  a  subject  of  a  separate 
ASPEN  working  report,  which  will  be  completed  during  the  next 
guar  ter , 
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The  following  programs  were  tested: 

1.  AFRAC  from  PLOWTRAN  simulation  system,  Monsanto  Co. 

2.  Distillation  Simulation,  DS-02,  Oleson  &  Associates 

3.  PRAKB  from  FLOWTRAN  simulation  systems,  Monsanto  Co. 

4.  MADCAP,  System  Analysis  Control  and  Design  Activity 
(SACDA) ,  University  of  Wester  Ontario. 

5.  Program  written  by  J.F.  Boston. 

6.  SSI-100,  Simulation  Sciences  Inc. 


2. 


A  brief  summary  of  the  evaluation  of  the  distillation 
programs  is  as  follows. 

1.    ASPEN  needs  to  acquire  an  equation-solving  type 

distillation  program.   Such  programs  enable  direct 
solution  of  any  design  specifications  and  (sometimes) 
direct  solution  of  systems  of  distillation  columns 
connected  with  recycle  loops, 

ASPEN  should  acquire  the  MADCAP  program  distributed 
by  SACDA,  University  of  Western  Ontario.   The  program 
is  an  equation-solver.   It  employs  sparse  matrix  tech- 
niques to  invert  and  store  the  system  Jacobian.   Thus, 
it  can  solve  multiple  colums  connected  with  recycle 
loops,  simultaneously.   Contained  in  a  loop  may  be 
heat  exchangers,  pumps,  valves,  flash  drums.   The 
program  generates  automatically  initial  guesses  for 
all  of  the  system  variables. 
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3.    ASPEN  should  acquire  the  distillation  program  by  Dr. 
J.F.  Boston.   It  is  a  rating  case  algorithm.   Its 
characteristics  are  exceptional  stability  and  small 
execution  times.   It  is  expected  that  this  program 
would  be  used  if  a  user  has  a  highly  nonideal  system 
and  can  not  provide  partial  derivatives  with  respect 
to  composition  for  activity  coefficients. 

7.1.4   SOLIDS  HANDLING 


The  following  have  been  major  sources  identified  through 
the  software  survey  for  solids  handling:  Bechtel  Corporation, 
University  of  Houston,  University  of  Pennsylvania,  University 
of  Pittsburgh,  University  of  Queensland  (Australia) . 

Bechtel  Corp.  has  developed  a  material  and  enthalpy  balance 
computer  program,  COALBAL  under  ERDA  contract  No.  EX-76-01-2370, 
COALBAL  calculates  material  flow  rates,  temperatures,  enthal- 
pies, pressures,  and  stream  compositions  for  all  coal  interface 
operations  following  live  storage.   The  project  staff  has  dis- 
cussed the  program  with  the  Bechtel  personnel. 

At  the  University  of  Houston  the  CEDA  program  was  developed 
to  handle  control  equipment  for  particulate  air  pollutants 
under  a  contract  with  the  Environmental  Protection  Agency, 
North  Carolina.   A  free  version  of  CEDA  source  listing  was 
obtained  from  the  EPA  in  October. 
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Under  a  subcontract  of  ASPEN,  several  solids-handling 
programs  have  been  developed  at  the  University  of  Pennsyl- 
vania.  The  programming  of  fluidized  preheaters,  solid- 
entrained  flow  dryers,  cyclones  and  crushers  and  grinders  was 
finished  in  November.   A  tape  of  the  source  code  of  these  pro- 
grams and  all  pertinent  documentation  was  obtained  from  the 
University  of  Pennsylvania. 

The  ASPEN  project  has  also  acquired  a  copy  of  the  programs 
written  at  the  University  of  Pittsburgh  and  the  University  of 
Queensland. 

Detailed  study  of  the  available  solids  handling  programs 
has  led  to  the  following  conclusions: 

.1.   Programming  style  of  various  programs  is  so  different 
that  the  incorportion  of  the  programs  into  ASPEN  would 
require  practically  re-writing  of  the  programs. 
2.    As  a  rule,  the  programs  incoporate  very  simple 

models.   Therefore,  the  programs  do  not  represent 
an  adequate  technical  basis  for  development  of  ASPEN 
modules. 

A  literature  survey  has  shown  that  the  most  advanced  solids 

separation  models  are  being  developed  at  the  University  of 

Cincinnatti  by  Prof.  Licht.  ASPEN  model  for  solids  handling 
will  be  based  on  that  work. 
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7.1.5.   MATHEMATICAL  LIBRARY 

The  ASPEN  project  has  acquired  a  library  of  numerical 
algorithms  from  Harwell,  England.  The  library  contains  a 
number  of  equation  solving  and  optimization  prcesses. 

The  programs  are  currently  being  used  by  the  staff  in 
development  of  the  ASPEN  system.   Appropriate  routines  will 
be  incorporated  in  the  final  system. 

7.1.6   SIZING  AND  COST  ESTIMATION  PROGRAMS 


During  the  last  year,  examination  and  evaluation  of  cost 
estimation  programs  was  carried  out  by  using  a  sample  problem. 
A  preliminary  economic  analysis  of  the  IGT's  HYGAS  hydrogasi- 
fication  was  chosen  as  a  sample  program.   Basic  information  was 
taken  from  the  final  reports  on  the  process  (specifically  ERDA 
report  76-47  for  a  plant  producing  2550  Mscfd  of  High-Btu  gas). 
Two  cost  estimation  programs  were  tested:  (1)  the  PROVES  pro- 
grams (available  from  Mr.  Guptav  Engedy)  and  PEPCOST  (available 
from  Stanford  Research  Institute) 

The  following  are  summaries  of  program  functions  in  PROVES 
and  PEPCOST  programs. 
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11 


111. 


IV. 


PROVES  can  be  divided  into  the  following  substem  and  their 
functions: 

i.    MODEL:  a  simulation  program  for  material  balance 

calculations  not  including  physical  properties,  phase 
equilibria,  heat  balances,  or  transport  phenomena. 
SCOPE:  a  program  for  sizing  and  costing  common  types 
of  equipment. 

INVEST:  a  program  for  the  esimation  of  plant  invest- 
ment or  fixed  capital  based  on  Hackney's  Equipment 
Ratio  method  (1960) . 

EFFECT:  a  program  for  economic  evaluation  of  chemical 
processes  including  approximate  investment  cost  and. 
detailed  manufacturing  cost  estimates,  sales  volume 
and  selling  price  forecasts,  profitability  analysis 
and  sensitivity  studies. 

On  the  other  hand,  PEPCOST  provides  the  following 
capabilities. 

i.    A  cost  data  bank  based  on  S.R.I,  developed  corre- 
lations. 

Equipment  costing  routines  for  major  equipment  classes 
Three  methods  for  estimating  fixed  capital  investment: 
Hirsh  and  Glazier  analytical  method  (1960) ,  Miller 
factored  method  (1965) ,  and  Guthrie  modular  method 
(1969) 


11. 
iii. 
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iv.    Estimation  of  production  cost,  working  capital  cost, 
start-up  cost,  utilities  and  raw  material  costs,  etc. 

V.    Estimation  of  average  selling  price  of  product. 

For  the  evaluation,  some  assumptions  were  made.   Namely 
equipment  sizes  given  by  the  Bureau  of  Mines'  report  were  used 
to  run  PEPCOST  program  which  calculated  individual  equipment 
cost  and  the  plant  capital  investment.   On  the  other  hand,  for 
running  PROVES,  the  total  major  equipment  cost  by  the  Bureau  of 
Mines'  report  was  used  because  PROVES  may  not  allow  to  specify 
individual  equipment  size  data  to  estimate  its  cost  and, 
furthermore,  the  purpose  of  the  evaluation  was  to  compare  the 
cost  results  from  different  programs.   The  results  of  major 
equipment  costs  by  the  Bureau  of  Mines  and  PEPCOST  show  no 
significant  differences.   Moreover,  the  capital  investments 
estimated  by  the  Bureau  of  Mines,  Hackney's  method  in  PROVES, 
and  Guthrie's  method  in  PEPCOST  do  not  differ  from  each  other. 
The  results  were  shown  in  the  7th  ASPEN  Quarterly  Progress 
Report.   However,  the  other  methods  provided  in  PEPCOST,  the 
Miller  method  and  Hirsh  and  Glazier  method,  gave  different 
results.   This  means  that  Guthrie's  method  and  Hackney's  method 
may  give  reasonable  results  and  were  determined  to  be  included 
in  the  ASPEN  system. 
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These  programs  use  different  definitions  and  terminology  so 
that  it  is  hard  to  compare  Operating  cost  estimates  and 
manufacturing  cost  estimates  by  specifying  a  minimum  discounted 
cash  flow  rate  of  return. 

In  order  to  evaluate  sizing  and  costing  programs,  we  chose 
a  sample  problem  for  the  separation  of  a  mixture  of  HCl,  ben- 
zene and  monochlorobenzene  (MCB)  which  is  described  in  the 
FLOWTRAN  user's  manual.   The  processing  system  consists  of  an 
absorber  tower,  a  distillation  tower,  two  heat  exchangers, 
flash  vessel  and  a  pump.   The  detailed  description  about  the 
sample  problem  is  shown  in  Fig.  7.1,  and  material  balance  data 
were  taken  from  FLOWTRAN's  results. 

There  are  several  kinds  of  sizing  and  costing  programs. 
However,  from  the  viewpoint  of  general  purpose  programs,  there 
are  now  only  two  programs  available  for  ASPEN.   These  are 
FLOWTRAN  and  PROVES.   Therefore,  the  software  evaluation  for 
sizing  and  costing  programs  is  limited  to  these  two  programs. 

Before  running  PROVES,  some  assumptions  were  made  and  are 
shown  in  Table  7.1.   The  results  of  sizing  and  costing  of 
individual  equipment  are  shown  in  Table  7.2. 

The  results  show  relatively  large  differences.   The  major 
differences  may  come  from  the  difference  of  the  sizing  and 
costing  methods,  physical  properties  and  unit  operation 
models.   For  further  evaluation  of  sizing  and  costing  models, 
some  referee  data  on  actual  equipment  size  and  costs  are 
required. 
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FIGURE  7.1  Process  Flow  Diagram  for 
Sample  Problem 
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Table  7.1 


ASSUMPTIONS  ON  RUNNING  PROVES 


1.  All  the  material  balance  data  were  specified  from 
FLOWTRAN's  results. 

2.  Cost  index  is  assumed  to  the  150  (same  as  FLOWTRAN's) 

3.  Physical  properties  are  specified  as  follows: 


MW 

Sp  Gr 

Viscosi 

•ty 

Temp 

CpV 

C  L 

Latent 
Heat 

HCL 

36.47 

1.268 

1.4 

50.0 

6.9 

6.9 

105.8 

BENZENE 

78.11 

0.815 

0.31 

80.1 

0.46 

0.252 

94.14 

MCB 

112.5.6 

1.071 

0.40 

130.6 

0.46 

0.274 

77.59 

*Using  Metric  Unit  (CP,  *C  cal/gC,  cal/g) 


4.    Utility  unit  costs  are  given  as: 


Electricity  .15  $/KWH 

Stream,  260^F         1.75  $/MLB 
Cooling  Water,  80°F    .03  $/M  GAL 


Table  7.2   SUMMARY  OF  SIZING  AND  COSTTNn  RESULTS 
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HEAT  EXCHANGER 

HI 
(FLOATING  HEAT) 


HEAT  EXCHANGER 

H2 
(FLOATING  HEAD) 


PRESSURE  VESSEL 
Fl 

(VERTICAL) 


PUMP 

PI 
(CENTRIFUGAL) 


DISTILLATION 
COLUMN 
Dl 


EXCHANGER  ARE,  SQ  FT 
fnCAT  DUTY,  MBTU/IIR 
EXCHANGER  COST,  $ 
UTILITY  COST,  $/HR 

EXCHANGER  AREA,  SQ  FT 
HEAT  DUTY,  MBTU/HR 
EXCHANGER  COST 
UTILITY  COST,  $/HR 

LIQUID  LEVEL,  FT 
DRUM  LENGTH,  FT 
DRUM  DIAMETER,  FT 
WALL  THICKNF,SS,  IN 
CAPACITY,  GAL 
VESSEL  COST,  $ 

FLUID  HP,  HP 
I3RAKE  IIP,  HP 
DRIVER  HP,  HP 
PUMP  COST,  $ 
MOTOR  COST,  $ 
I^LECTICITY,  $/H 

DIAMETER,  FT 
HEIGHT,  FT 
l\    or  TRAYS 
SHELL  THICKNESS 
SHELL  COST,  $ 
TRAY  COST,  $ 
REBOILER  DUTY  MBTU/H 
REBOILER  AREA,  SQ  FT 
REBOILER  COST,  $  ' 
STI-AM  COST,  $/Ii 
CONDENCI'R  DUTY  MBTU/H 

CONDENCKR  AREA,  SQ  FT. 
COMDENCI'U  COST,  $ 
WATER  COST,  $/H 
REFLUX  TANK 

CAPACITY,  GAL 
RRFLUX  TANK  COST,  $ 
REFLUX  PUMP  CAPACITY, 

GPM 
REFLUX  PUMP  COST,  $ 
TOTAL  COST,  $ 


FLOWTRAN 

70.88 

1,187 

1,180 

1.19 

91.63 

1,132 

1,420 

1.13 

3.68 

7.68 

2.00 

.31 

PROVES 


89 


2061 

0.33 

1.09 

1.30 

14  3 

163, 

.03 

3.0 

55.0 

30 

.438 

8,985 

3,460 

2,686 

223.9 

2,690 

3.12 

2,463 

216.0 

2,620 

.59 


1/ 187  speci  f  ied 
2, 200  (5000)  * 
2.65 

72 

1,132    (specified) 
1,900    (3,800)* 
0.  34 


17,755 


115. 

700    (2,000)* 


500     (700)* 

.03 

3.4 

18 

19,800     (14,700) 

2,519 
439 

4200     (9600)* 

5.6  3 
2,  34  3 

120 
2600     (7,900)* 
.49 
50 

400     (1,400)* 

26 

800     (1,400)* 
27,700     (33,000) 


'F,MARKS*    AH    costs    are    based    on    carbon    steel.       However,    costs    in    the 
parentheses    are    based    on    stainless    steel. 
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7.1.7   MODIFICATION  OF  THE  ACQUIRED  SOFTWARE  AND  INCORPORATION 
INTO  ASPEN 

FLOWTRAN  SYSTEM 


VLE  -  It  is  estimated  that  a  total  of  2  man-months  will 
be  required  to  convert  the  programs  to  ASPEN  data 
structure. 

Unit  Operations  -  Parameter  and  retention  vectors  of 

individual  blocks  will  be  expanded  to  include  more 
internal  variables.   This  will  enhance  the  block 
convergence  in  recycle  calculations.   Blocks  will  be 
modified  to  handle  solids  as  non-volatile  components. 
Flash  will  not  accept  an  entrainment  factor  as  para- 
meter (s)  describing  a  real  process  unit.   Total  time 
required  for  modification  of  applicable  blocks  is  6 
man  months. 

Physical  Properties  -  Models  for  activity  coefficients, 

liquid  density  (Cavett)  vapor  pressure  (Cavett) , 
enthalpy  (Cavett)  will  be  included.   It  will  take  2 
man  months  to  incorporate  these  models  into  ASPEN 
system. 

Sizing  and  Costing  -  Modification  of  the  applicable 

FLOWTRAN  routines  will  require  4  man  months. 
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Convergence  routines  -  Due  to  a  different  data  structure, 
none  of  the  FLOWTRAN  routines  is  applicable.   New 
routines  wil  be  written  by  the  ASPEN  staff. 
Distillation  Calculations 

It  is  estimated  that  a  conversion  of  an  acquired  program 
may  take  up  to  3  man  months,  depending  on  the  complexity  of  the 
program. 
Mathematical  routines 

Modification  of  an  existing  algorithm  for  solving  nonlinear 
equations  and  its  incorporation  into  ASPEN  will  typically  take 
two  to  three  days. 
Solids  handling 

All  programs  will  be  written  by  the  ASPEN  staff. 

7.2   WORK  FORECAST 


Modification  of  FLOWTRAN  modules  will  be  completed  by  the 
end  of  September,  1978, 

Incorporation  of  an  acquired  distillation  program  will  be 
completed  shortly  after  a  delivery  of  the  program. 
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TASK  8:   INTEGRATION,  TESTING  AND  DOCUMENTATION  OF  ASPEN  SYSTEM 

8.1  WORK  ACCOMPLISHED 

Program  specifications  are  being  prepared  for  various  mod- 
ules that  make  up  the  executive  system  of  ASPEN.   Coding  and 
testing  also  have  begun  on  some  modules. 

The  specification  are  being  prepared  in  greater  detail  than 
originally  planned.   This  will  reduce  coding  errors  and  speed 
up  the  implementation.   The  specification  forms  are  shown  in 
Appendix  B. 

8.2  WORK  FORECAST 


During  the  next  quarter,  coding  and  testing  will  continue. 
This  work  is  scheduled  for  completion  towards  the  end  of 
August.   Simultaneously  work  will  begin  on  the  specification 
of  benchmark  problems. 
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APPENDIX  A 

FORTRAN  Programming  Standards 

for 

ASPEN  Pro-ject 
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1.0   INTRODUCTIOM 


The  purpose  of  this  document  is  to  provide  the  necessary 
guide  lines  and  standards  in  writing  well  documented  and  easily 
maintained  programs. 

The  preparation  of  the  standards  is  developed  with  two 
major  goals  in  mind: 

1,    Program  Style 

The  coding  Structure  is  rigidly  defined  and  provides  a 
standard  orderly  method  for  arranging  the  program  in  a 
hierarchically  structured  format.   Checklists  are 
given  for  various  portions  of  the  code  to  ensure  a 
well  written  program. 


2.   Program  Portability 

A  superset  of  AMSI  Fortran  is  derived 
Fortran,  PFORT  (Oell's  large  portable 
Fortran) , 


IMSL  Converter,  and  Fortran 
manuals  for  the  following  large  scale 
Univac/  CDC,  Honeywell,  Burroughs,  DEC 


from  AMSI 
subset  of 
reference 
computers : 
and  Xerox. 


IBM, 


The  document  is  meant  to  be  a  supplement  to,  but  does  not 
take  the  place  of  Fortran  manuals  of  the  various 
manufacturers.   Also,  as  the  standards  have  not  been  field 
tested  on  the  various  computers,  the  efficacy  of  the 
documentation  cannot  be  guaranteed.   It  is  hoped  that 
deficiencies  in  the  documentation  will  be  brought  to  our 
attention,  in  order  that  we  can  improve  the  documentation. 


(i; 
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2.  0  progra;4  structure 

Under  this  section,  the  general  style  as  well  as  the 
structure  of  a  program  unit  is  considered. 

2. 1   GENERAL  PROGRAM  STYLE 

2.1.1  Isolation  of  System  Dependent  Code 

A  maximum  effort  should  be  made  to  ensure  portability  of 
code.   However,  some  programs  are  necessarily  tailored  to  a 
particular  system.   Programs  for  character  manipulation  and 
those  involving  direct  access  files  are  of  such  type.   In  these 
cases,  the  code  should  be  isolated  in  a  subprogram,  if  possible 

2.1.2  Isolation  of  Code  Liable  to  Change 

^  In  a  software  system,  there  are  necessarily  some  oortions 
of  code  liable  to  change.  If  such  portions  can  be  forseen  at 
system  design  time,  and  isolated  at  programming 
make  the  system  much  easier  to  maintain. 


time,  it  would 


2,1.3   Program  Flow 


The 
from 


flow  of 


is  one 


a  program  should  be  straight  forward,  it  should 
top  to  bottom  instead  of  jumping  around.   This 
of  the  important  principles  of  structured  programming. 
Implementation  of  this  standard  makes  the  program  less 

easier  to  maintain. 


error-prone  and 
2. 14   Modularity 


It  is  desirable  for  a  program  unit  to  perform  a 
well-defined,  complete  function.   This  makes  the  program  easv 
to  write  and  test  during  implementation.   The  finished  program 
unit  is  then  easier  to  describe  in  the  system  design  document. 
In  addition,  such  a  program  unit  might  be  used  by  the  system  in 
several  places. 

One  major  disadvantage  however  is  associated  with  the 
overhead  involved  in  the  linking  of  program  units.   Therefore, 
small  program  units  should  be  carefully  examined  to  see  if  thev 
could  be  written  as  statement  functions. 


(2) 
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2.2   STRUCTURE  OF  PROGRAM  UNIT 

2.2.1  Types  of  Program  Units  Allowed 

A  program  unit  may  be  anyone  of  the  following; 
-a  main  program 
-a  subroutine-subprogram 
-a  function-subprogram 
-a  block-data-subprogram 

2.2.2  Restrictions  on  Block  Data  Subprograms 
1. 


2. 

3. 


2.2.3 
1. 

2. 


2.2.4 
1. 


External  statements  cannot  appear  in  a  block  data 
subprogram. 

A  common  statement  in  a  block  data  subprogra  must  have 
a  common  name. 

One  and  only  one  block  data  subprogram  can  initialize 
a  given  common  block.   (This  rule  avoids  the 
possibility  that  initialization  of  named  common  may 
depend  upon  the  order  of  loading  the  subprograms) . 

Restrictions  on  Subroutines  and  Function  Subprograms 

Entry  statements  are  an  augmentation  to  the  standard. 
As  it  is  available  in  all  the  environments,  it  may  be 
used  when  it  has  no  associated  arguments. 

Literals  should  not  be  used  as  actual  arguments  in 
subprograms.   They  should  be  variable  names  whose 
value  is  given  by  a  Hollerith  string  in  data 
statements. 

Restrictions  on  Function  Subprograms 

If_an  expression  contains  a  reference  to  a  function 
which  is  defined  by  an  external  function  subprogram, 
then  evaluation  of  that  function  reference  must  not 
alter  any  other  value  in  the  statement  in  which  the 
reference  occurs. 

For  example,  each  of  the  3  usages  of  external  function 
IFF  is  incorrect: 


(3) 
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1  =  1 

J=I+IFF(I) 

J=(MAXO   (I,  IFF  (I)) 

A(I) =IFF(I) 

STOP 

END 

INTEGER  FUNCTION  IFF(K) 

K  =  K  +  1 

IFF=K+1 

RETURN 

END 

If  a  statement  contains  two  (or  more)  references  to 
the  same  function  subprogram  with  an  identical 
argument  list  in  each  case  then  the  evaluation  of  each 
of  tnose  function  references  must  produce  identical 
results  m  each  case,  no  matter  in  what  order  thev  are 
evaluated.  ^ 

For  example,  the  following  usage  of  function  F  is 
incorrect: 


COMiMON  I 

DIMENSION 

1  =  0 

J=iMINl  (1. 

A(I)=1 

STOP 

END 

FUNCTION 

COMiMON  I 

1  =  1  +  1 

F=I 

RETURN 

END 


A(2) 

+  F(l.  ) 

F(I) 


F(l.  )) 


4) 
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3.0  CODING  STRUCTURE 

In  this  section,  we  will  set  up  a'  template  for  a  program 
unit.   The  different  sections  of  the  template  will  then  be 
taken  apart  for  some  discussion. 

A.  Statement  Ordering  in  a  Program  Unit 

n.  Comment  Statements 

C.  Statement  Labels 

D.  Specification  Statements 

E.  Statement  Function  Specifications 

3. 1  Statement  Ordering  in  a  Program  Unit 

The  diagram  below  shows  the  statement  ordering  of  a  program 
unit. 


Subprogram  Statement 


Specification  Statements 
DIMENSION,  COMMON,  EQUIVALENCE,  EXTERNAL,  type) 


Comment 


Lines 


Data  Statements 


Statement  Function  Definitions 


Format 
Statements 


Executable 
Statements 


END  Statement 


Although  Fortran  allows  format  statements  to  be  anywhere 
inside  a  program,  it  is  strongly  recommended  to  group  them 
together  at  the  beginning  of  the  program. 


(5) 
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3. 2   Comment  Statements 

Comments  within  a  program  serve  as  documentation  of  the 
program. 

3.2.1   The  Prologue  Comment  Statements 
The  prologue  should  contain: 


1. 
2 

3. 

4. 

5. 
6. 
7. 


8. 
9. 

10. 


Name  of  module:  the  name  should  be  less  than  or  equal 
to  6  characters. 

Title  of  module:  a  longer,  more  meaningful  explanation 
of  the  module. 

Purpose:  function  of  module  is  concisely  explained. 

Task,  subsystem,  system:  this  explains  the 
relationship  of  the  module  to  the  rest  of  the  system. 

Written  by,  and  date  written. 

Last  revised  by,  and  last  revision  date. 

Description  of  files  used:  this  should  include  the 
file  name,  title  of  file,  Fortran  Unit  No,  Input  or 
Output,  created  by  or  used  by  which  module(s),  if 
sequenced  -  the  sequence  order,  access  mode  of  the 
file,  and  a  brief  description  of  the  file. 

A  list  of  the  subroutines  called. 

The  calling  sequence  of  the  module. 

A  description  of  the  variables  in  the  calling  sequence 
as  well  as  other  important  variables  inside  the  module. 


3.2.2   Inter-orocram  Comment  Statements 


Within  a  program,  comments  ihould  precede  logical 
paragraphs.   For  readability,  all  comment  cards  should  start  at 
column  10  and  should  be  preceded  and  followed  by  blank  comment 
cards. 


3.3   Statement  Labels 
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A  statement  label  may  be  in  the  set  1,  2,     ,,.,    99999. 

Leading  zeros  are  ignored  in  statement  labels,  as  are  embedded 

blanks.   For  the  readability  and  maintainablili ty  of  the 

program  units,  the  following  2  rules  are  set  up  for  statement 
labels. 

1.  For  format  statements,  the  numbers  10  to  200  are 
reserved.   The  format  statements  should  increase  in  ' 
intervals  of  10.   All  format  statements  should  be 
grouped  together. 

2.  For  other  statement  labels,  the  numbers  210  to  99990 
are  allowed,  they  should  also  increase  in  intervals  of 
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3  .  4   Specification  Statements 
3.4.1   The  DIMENSION  Statement 


1. 


2. 


In  subprograms,  dimensions  of  arrays  should  be 
explicitly  declared  whenever  possible.   This  enables 
debugging  by  turning  on  subscript  checks,  it  also 
provides  better  documentation. 

Object  time  dimensions  should  be  transmitted  as  actual 
arguments  and  not  in  common.   Also,  corresponding 
dummy  and  actual  arguments  may  have  a  different  number 
of  indices  {e.g.  vector  f-^  matrix)  . 


3. 


Subscript  computations  at  object  time  are  expensive,  a 
good  rule  would  be:  "Never  use  a  N-d imensional 
when  an  array  of  (N-1)  dimensions  will  do". 


array 


3.4.3   The  COMflON  Statement 

It  should  be  noted  that  in  common  statements: 

1.  If  a  common  name  appears  more  than  once  in  a 
program-unit  or  within  a  common  statement,  then  the 
associated  common  entries  are  strung  together  in  the 
order  of  their  appearance. 

2.  Within  a  common  block  ,  complex  and  double  precision 
entities  must  precede  all  real,  integer  or  logical 
entities.   This  prevents  improper  word  alignment  of 
data. 
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3.4.3   The  Type  Statement 

Type  statements  may  take  on  one  of  two  forraS/  the  explicit 
type  statements  and  the  implicit  type  statements. 

3.4.3.1   The  explicit  Type  declaration  should  be  of  the  form:  ' 

t   vl,  v2.  . . . vn 

where 

t  is  integer,  real,  double  precision,  complex  or  logical 
vl  is  a  variable  name,  array  name,  function  name  or  array 
declarator. 

Note: 


The  IBM  type  declaration  t*n,  is  not  portable,  though  real  *8 
is  available  on  all  machines  except  CDC.   Also,  there  is  no 
ANSI  equivalent  for:  integer  *2,  complex  *16  and  logical  *1! 

3.4.3.2   Implicit  Type  Declarations 

The  implicit  type  declaration  is  also  available  on  most 
computers  and  is  of  the  format: 

IMPLICIT  t  (aix,  ai2/  ...)/.../  t(ani,  3^2/  •••) 

where  t  is  integer,  real,  real  *8,  complex,  or 
logical  and  aii  is  a  single  alphabetic  character. 

Note ; 

The  reason  that  real  *8  is  used  instead  of  double  precision 
is  because  it  works  on  all  machines  except  CDC  where  double 
precision  is  not  requi'red  any  way.   Vvhereas,  implicit 
double  precision  is  invalid  on  some  machines. 
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3 . 5   Da -a  Statement 

3.5.1   Format  o£  Data  Statements 

A  data  initialization  statement  is  of  the  form 

DATA  kl/dl/,  k2/d2/,  ...kn/dn/ 

where:    ki  is  a  list  containing  names  of  variables,  array 
elements  and/or  array  names.   Note  the  subscript 
expression  of  array  must  be  an  integer  constant. 

di  is  a  list  of  constants,  any  of  which  may  be 
preceded  by  j*. 

j  is  the  repeat  count  and  is  an  integer  constant. 
Note: 


a. 


b. 


If  list  items  of  the  data  statement  appear  in  a  COMMON 
statement,  they  may  only  appear  in  a  labelled  COMMON 
in  a  BLOCK  DATA  subprogram. 

Note  that  in  IBM  Fortran  DATA  in  the  above  statement 
may  be  replaced  by  a  type  soecif ication  (e.g.  REAL, 
DOUBLE  PRECISION) .   This  usage  is  not  portable. 
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3.5.2   Usage  of  Data  Statements 

A  DATA  statement  is  one  of  the  several  ways  for 
initializing  of  data.   It  should  be  used, 


1. 


2. 


1^ 


2^ 


For  initialization  of  standard  I/O  devices.   Standard 
I/O  devices  are  the  card  reader  or  console  input 
printer  or  console- output  and  the  card  punch.   Unit 
numbers  for  these  standard  I/O  devices  are  svstem 
dependent.  _  Thus,  integer  variables  should  be  assigned 
to  the  devices  and  their  values  assigned  in  a  data 
statement. 

For  initialization  of  variables  and  small  arrays. 

Thus, 

CI  =  1.!? 

no  1^  1=1,1^ 

F(I)  -   FLOAT (I) 
CONTINUE 

should  be  receded  as, 

DATA  CI,  F/2*l.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.,  1]?./ 

The  receded  version  avoids  calls  to  symbols. 

Data  statements  should  not  be  used,  however,  for  the 
initialization  of  very  large  arrays.   Thus,  on  the  IBM 
machine,  the  load  module  of  the  following  orogram 
takes  3  tracks, 

niMENSON  A(30r^^^) 
DO  2i2f  1  =  1,  3^^^0 
A(I)  =  ^.^ 

CONTINUE 
END 

On  the  other  hand,  in  the  example  below  initialization 
of  the  same  array  by  a  DATA  statement  takes  13  tracks 
and  considerably  more  cpu  time  to  compile  and  execute, 

DIMENSION  A(3J3f^!7{7) 
DATA  A/3i7^{J^*  ^./ 
END 
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3 . 6   The  Statement  Functions 

3.6.1   Forinat  of  Statement  Functions 

It  is  a  function  defined  by  a  function  definition  within 
the  program  unit  in  which  it  is  referred  to 

A   statement  function  is  of  the  format: 

function__name  (xl,  x2,  ...,    xn)  =  expression 

where  xl,  ...,  xn  is  one   or  more  dummy  arguments. 

^•6.2   Restrictions  on  Using  the  Statement  Functions 

In  defining  a  statement  function,  care  should  be  taken  to 
avoid  the  following  pitfalls. 


1. 
2. 


3. 


No  array  elements  can  appear  in  the  expression. 

Aside  from  dummy  arguments,  expression  may  contain 
only:  non-Hollerith  constants,  variable  references, 
intrinsic  function  references,  references  to  previous 
defined  statement  functions  and  external  function 
references. 

The  name  of  a  statement  function  must  not  appear  in  an 
EXTER.NAL  Statement,  or  as  a  variable  name  or  an   array 
name  in  the  same  program  unit. 
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3«"7   Executable  Statements 

3.7.1   Arithmetic  Statements 

^•■7.1.1   Results  of  Mixed  Mode  Arithmetic: 

1.    In  an  arithmetic  expression  evaluation  pxcept 

exponentiation,  following  mixed  modes  are  allowed 
giving  results: 

-real  op  double  precision  or  vice  versa,  result 
IS  double  precision. 


2. 


3.7.1.2 
1. 


-real  op  complex  or  vice  versa,  result  is  complex. 

In  an  exponentiation  expression,  following  mixed  modes 
are  allowed  giving  results: 

-double  precision  **integer,  double  precision 

real,  real**double  precision,  result  is  double 
precision. 

-complex**integer,  result  is  complex. 
Pitfalls  on  Usage  of  Arithmetic  Statements 

Il^^fr^'^-^^?'"^''^  example  shows  we  should  avoid  comparing 
RLAL  numbers.  ^ 


TEST. FORT 
00010  C 
00020  C 
00030  C 
00040 
00050 
00060 
00070 

00080     10 
00090     20 
00100 
READY 
fort  test 

Gl  COMPILER  ENTERED 
SOURCE  ANALYZED 
PROGRAM  NAI-IE  =  MAIN 
*   NO  DIAGNOSTICS  GENERATED 
READY 

loadgo  test  fortlib 
A=  I.OOIS  NOT  EQUAL  TO  B=  1.00 
READY 


PURPOSE:   TO  ILLUSTRATE  THE  PERIL  OF 
COMPARING  REAL  NOS .   IT  ALSO  SHOWS  THE 
COMPUTER  HAS  NO  COMMON  SENSE  ' ' ' 
A=l./3.*3. 
B  =  l. 

IF(A.EQ.D)  WRITE(6,10)  A,B 

IF(A.NE.B)  WRITE(6,20)  A,B 

FORMATC  A=',F5.2,'IS  EQUAL  TO  B=',^5  2) 

FORMAT ('  A=',F5.2,'IS  NOT  EQUAL  TO  B=',F5.2) 

END  '   •  ; 
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2.  To  avoid  round-off  errors,  terms  in  an  arithmetic 
expression  should  be  grouped  selectively.   Avoid 
performing  arithmetic  on  numbers  widely  different  in 
magnitude.   Also  avoid  performing  subtractions  on 
numbers  which  are  approximately  equal. 

3.  In  performing  exponentiation,  a  variable  should  be 
raised  to  an  integer  constant  if  possible,  instead  of  an 
integer  variable,  a  real  constant  or  a  real  variable. 
This  is  because  the  former  is  usually  accomplished  via 
in-line  code  generated  by  the  compiler,  while  the  rest 
require  calls  to  FORTRAN  library  routines. 

3.7.1.3   Order  of  Evaluation  of  Arithmetric  Expressions 

The  order  of  evaluation  of  arithmetic  expression  (in 
descending  order)  is: 

evaluation  of  functions,  **,  X  /,  +-,  relationals 
(.GT.,  .GE.,  .LT.,  .LE. ,  .EQ.,  .ME,),  NOT.,  .AND.,  .OR. 

3.7.2   GO  TO  Statements 


COMPUTED  GO  TO  Statements:   careful  check  should  be  made 
that  the  number  of  statement  labels  should  be  less  than  or 
equal  to  the  integer  variable  reference.   If  the  integer 
were  larger  than  the  number  of  statement  labels,  some 
systems  will  abort,  while  others  will  go  to  the  last 
statement  label. 

ASSIGN  GO  TO  statements:   this  tends  to  make  the  flow  of 
program  to.  jump  around.   It  should  not  be  used. 

UNCONDITIONAL  GO  TO  statements:  it  should  always  go 
forwards  only  except  in  the  case  of  DO  ^^THILE  constructs. 


3.7.3  DO  Statements 

Do  statements  should  always  be  ended  by  CONTINUE 
statements.   Also  care  should  be  taken  that  loop  independent 
expressions  should  not  be  inside  a  loop,  for  optimization 
purposes. 

3.7.4  PAUSE  Statements 

PAUSE  statements  should  be  avoided. 

3.7.5  ST^;?  Stater.ents 

370?  statements  should  be  used  for  main  program  end  or 
acnornal  termination  only. 
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3.8  Input/Qutput  Statements 

3.8.1   Sequential  Input/OutPut  Statements 

1.   Forinatted  READ/WRITE  statements 

The  statements  are  used  in  conjunction  with  the  FORMAT 
statements  to  provide  editing  and  conversion  information 
itrlnn"!    ""^^^ .''''^^'^^^J ^P^ ^^^^tatiou   and  the  external  character, 
strings.   It  should  be  used  for  print  out  only. 

Formatted  READ/WRITE  statements  are  of  the  form: 
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READ 
WRITE 


(u,  f)  k 


where   ^^is^an  integer  constant  or  integer  variable*  specifying 

fn'Lra'v^nLf+^^f  ^"^"^  ^^^^^  °^  ^  ^°^^^^  statement  or 
an  array  name+  whose  context  is  a  valid  format      ~" 
statement, 
1<  is  a  list 


Hints 


Note: 


:   The  I/O  unit  u  is  an  integer  ranging  from  1  to 
43.   As  the  unit  no.  for  card  reader  and  printer 
IS  machine  dependent,  u  should  be  defined  in  a 
common  and  in  a  data  statement  in  a  block  data 
subprogram. 

+:   The  array  containing  format  specification  may  be 
read  in  A-format  -  object  time  format.   This 
feature  is  very  useful  for  a  generalized  report 
writer.  ^ 

The  end=  and  err=  functions  of  read/write  statements 
is  not  a  standard. 
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2.   Unformatted  READ/WRITE  statements: 

Unformatted  READ/WRITE  is  of  the  form 


READ 
WRITE 


(u)k 


where   u  is  the  I/O  unit  number 

k  is  the  list  of  variables 

Unformatted  I/O  should  be  used  for  large  amounts  of  data 
which  are  intermediately  stored  for  later  usage  either  by  the 
same  or  by  other  programs.   For  example,  the  following  code 


10 


DIMENSIOM  X(IOO) 

DATA  INOUT/3/ 

FORMAT(10  0F8,3) 

VmiTE    (INOUT,10) {X(I) ,1=1,100) 


READ    (INOUT, 10) (X(I) ,1=1,100) 


should  be  receded  as: 

niMENSIOM  X(IOO) 
DATA  INOUT/3/ 
WRITE  (INOUT)  X 


READ  (INOUT)  X 

The  receded  version  provides  better  performance  in  1  ways.   CPU 
time  is  saved,  conversion  under  format  control  using  Fortran 
I/O  package  is  no  longer  required,  and  buffer  si:^e  for  reading 
the  same  amount  of  data  is  smaller.   Thr  formatted  version  of 
code  requires  300  characters  of  buffer  size,  while  the 
unformatted  requires  about  400  characters.   Also  the  receded 
version  has  improved  accuracy.   Under  format  control,  the 
accuracy  of  x  is  truncated  to  3  decimal  places 
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3.   Auxiliary  I/O  statements: 


3.8.2 


These  are  BACKSPACE  and  RE^VIND  that  provide  for 
positioning  of  an  external  file,  and  ENDFILE  which 
writes  an  end-of-file  on  the  file.   The  statement  is  of 
the  format:  KEYWORD  i,  where  i  is  an  integer  constant  or 
integer  variable  denote  are  I/O  unit  number.   Note  that 
these  I/O  statements  are  for  sequential  I/O  only. 

Direct  (Random)  Access  Input/OutPut 


All  large  computers  mentioned  in  section  1  have  this 
capability.   However,  the  syntax  is  different  for  each 
computer.   Thus,  this  kind  of  I/O  should  be  isolated  to 
subprogram. 

^•3»3   List  Directed  Input/Output 

feature  ^^Thtc^'u"'^!^ *'^S%!^^^P''  ""^^^^  ^"^  Burroughs  have  this 
teature.   This  kind  of  I/O  should  be  avoided. 

3.8.4   Formatted  Main  Storage  Transfer 

This  feature  is  again  machine  dependent.   Most  compu^ers 

unLo?H.M'  .   ^P  ""'''""  ^-"^"^  LOGICAL^.   This  kind  of  I/O  is 
unavoidable  for  Fortran  string  manipulation  and  should  be 
isolated  m  subprograms. 
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4.0   DATA  STRUCTURE 


4.1   The  Fortran  Character  Set 
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1.  There  are  3  types  of  character  sets  among  the  different 
environments: 

-EBCDIC  (Extended  Binary  Coded  Decimal  Interchange 

Code) 
-BCD  (Binary  Coded  Decimal) 
-ASCII  (American  National  Standard  Code  for  Infor 

Interchange) 

2.  Among  the  3  sets  the  following  47  characters  are  allowed: 

-(A-Z),  (0-9) 
-Special  characters: 

+-*/=()  .  ,  $  blank 

Note :    The  symbol  apostrophe  (')  is  not  standard  and 
not  available,  e.g.,  on  CDC. 

4 . 2   Data  Types  Allowed 

1.  ANSI  standard  allows  6  data  types: 

integer,  real,  double  precision,  complex,  logical, 
and  Hollerith 

Note :   Literal  strings  enclosed  in  apostrophes  are  not 

portable  and  H  format  should  be  used  where  possible. 

2.  In  addition,  2  other  types  are  available  on  different 
machines  in  slightly  different  syntax: 

-Statement  label  type:  this  data  type  is  associated  with 
the  non-standard  return  from  an  executable  subroutine, 

-Hexadecimal/Octal  types:  this  data  type  displays 
internal  representation  of  data.   It  is  a  machine 
specific  representation  made  up  of  Hexadecimal  (radix 
16)  and  Octal  (radix  8)  e.g.  IBM,  Xerox,  Burroughs, 
Prime  have  Hexadecimal  while  Univac,  CDC,  Honeywell, 
DEC,  Burroughs,  Harris  have  Octal. 

Note :   The  latter  2  types,  though  generally  available, 
should  be  avoided  if  possible. 
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4. 3  Variable  Names 

^*  ch^?!^^''^''?^^^  ?f"^^?  *^°  ^^^^^  ambiguity.   Ambiguous 
^^n^^L  'V^\^'^  '  '^'^'  ^"^  'Q'Q'  should  bl 
fu   ^^;  ^s^isble  names  like  XPOS  and  YPOS  are  better 
than  POSX  and  POSY  oeccer 

2.  Variable  names  should  be  less  than  or  equal  to  6 
characters.  m  «x  lu  o 

4.4  Array  Declarator 

An.  array  declarator  specifies  an  array  used  in  a  program 
It  may  be  m  a  type  statement,  DIMENSION  or  COMMON  statement^ 
It  must  have  the  format  v(i),  where  scacements. 

a.  V  is  a  symbolic  name, 

b.  i  is  composed  of  1  to  3  parameters.   Each  of  the 
vfrt^M^^^^t^  ^^  ^?  integer  constant  or  an  integer 
mainlr^^a'L')!'  ""''  '''^'''''    '^'   subprogram  and  not 

'^•S   Subscript  Expressions 

1.  A  subscript  expression  may  be  of  following  form: 

c*vJ:k 

where  c  and  k  are  integer  constants 
V  is  an  integer  variable 

2.  Nested  Subscripts  should  be  avoided.   Thus, 

A(IB(k))  =  iDj? 
should  be  receded  as 

J  =*  IB(k) 
A(J)  =  IDJJ 
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5.   Miscellaneous 
5.1 


UDoer  Limit  on  ■  scr.e  Fortran  Variables 


Item 

no,  of  characters  in  variable  names+ 

no.  of  integers  in  statement  labels 

no.  of  continuation  lines  of  1  statement 

no.  of  dimensions  in  an  array 

the  field  width  n  of  An  format* 

this-  field  width  n  of  nH  format 

na.-  of  digits  in  input/output  unit 
Identifier 


Limit 

6 

5 

19 

3 

4 

the  minimum  of  either  case  255  or 
19  continuation  CARDS. 


*■   First  character  must  be  An  alphabet. 

*  Most  computers  have  at  least  2  characters (by tes)  to  a  word.   In  the  minimum 

character  case/  we  can  make  the  literal  variable  of  type  double  precision. 
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5.2   Values  of.  Selected  Constants 
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Constant  Definition        IBM 

1.  No.  of  digits  in  single 
precision  decimal 
constants  7 

2.  No,  of  digits  in 
double  precision 
decimal  constants     16 

3.  No.  of  significant 
decimal  digits  in 

single  Pi^^cision      6.3 

4.  No.  of  significant 
decimal  digits  in 
double  precision    16.0 

5.  No.  of  bits  pet- 
single  storage 

unit  (word)  32 

6.  No.  of  characters 
(bytes)  per  word       4 

7.  No  of 'digits  in 
integer  constants       9 


XEROX 


UNIVAC 


HONEYW 


Dec 


16 


6.3 


16.0 


32 


18 

8.1 

18.0 

36 
6 

10 


18 
8.1 

19.3 

36 
6,8 

.10 


18 


8.1 


19.3 


36 


Burr 


11 


22 


CD 


11.1   14.0 


22.8 


10 


40 
6 

12 


28.0 

6 

10 

18 
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5  -  3  Single  Precision  or  Double  Precision? 

As  development  work  is  being  done  on  an  IBM  machine, 
real  values  will  have  to  be  of  type  double  precision.   Thus, 

1.  For  real  variables,  an  implicit  statement  must  be  placed  at 
beginning  of  each  subprogram  and  is  of  the  form: 

IMPLICIT  REAL*8   A-H,  0-2 

Explicit  declaration  is  then  required  to  override  this  for 
specific  variables. 

2.  Constants  must  be  explicitly  .  expressed  as  double 
precision.   For  example,  1.0  must  be  written  as  IDO  in  the 
simplest  double  precision  form. 

I.-   For  functions: 

a.  Statement  functions:  they  will  be  double  precision 
because  of  the  implicit  statement. 

b.  External  functions:  if  real,  they  should  be  declared 
of  type  double  precision,  e.g. 

DOUBLE  PRECISION  FUNCTION  FUNA  (X) 

c.  Library  functions:  the  double  precision  ones  must  be 
used,  e.g.  DSQRT  for  square  root. 

However,  to  enable  ease  of  conversion  to  single 
precision  for  some  machines,  the  following  2  conventions 
are  adopted: 

1.  Statements  containing  double  precision  declarations  should 
be  marked  out  by  preceding  the  code  with  a  'c**'  line. 

2.  Any  double  precision  library  function  or  external  function 
must  have  its  single  precision  counterpart  in  the  code  but 
commented  out  with  a  'c*'  in  columns  1  and  2.   Thus  if 
DSQRT  were  used  in  the  code,  the  following  code  must  appear: 

C*    DSQRT(X)  =  SQRT(X) 

For  a  list  of  S.P.  intrinsic  and  basic  external 
library  functions  and  their  D.P.  counterpart,  see  Appendix 
D  . 
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5.4 

List  of^-P/Dp  Intrinsic  and  Basic  External  Function  Names 
S-P.  D.P. 
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ALOG 

CLOG 

ALOGIO 

EXP 

CEXP 

SQRT 

CSQRT 

AS  IN 

ARSIN 

ACQS 

ARCOS 

ATAN 

ATAN2 

SIN 

COS 

TAN 

COTAN 

SINH 

COSH 

TANH 

ABS 

CABS 

ERF 

ERFC 

AMAXl 

AMINl 

AINT 

INT 


CONJG 

RKAL 
A I  MAG 

DIM 


DLOG 

CDLOG 

DLOGIO 

DEXP 

CDEXP 

DSQRT 

CDSQRT 

DAS  IN 

DARSIN 

DACOS 

DARCOS 

DATAN 

DATAN2 

DSIN 

DCOS 

DTAN 

DC 0 TAN 

DSINH 

DCOSH 

DTANH 

DABS 

CDA3S 

DERF 

DERFC 

DMAXl 

DMINi 

DINT 

IDINT 


GAMMA 

DGAMMA 

ALGAMA 

DLGAMA 

AMOD 

DMOD 

FLOAT 

DFLOAT 

SIGN 

DSIGN 

CMPLX 

DCMPLX 

DCONJG 

DRHIAL 
DIMAG 

DDIM 


FUNCTION 

Natural  logarithm 
Complex  natural  logarithm 
Common  logarithm 
Exponential 
Complex  exponential 
Square  root 
Complex  square  root 

Arc  sine  function 

Arc  cosine  function 

Arc  tangent  with  1  argument 

Arc  tangent  with  2  arguments 
Sine  function 

Cosine  function 

Tangent  function 

Cotangent  function 

Hyperbolic  sine  function 

Hyperbolic  cosine  function 

Hyperbolic  tangent  function 

Absolute 
Complex 

Error  function 
Complement  of  error  function 
Maximum  value 
Minimum  value 
Truncation  (real  value 

returned) 
Truncation  (integer  value 

returned) 
GAMMA  function 

Natural  log  of  GAMMA  function 
Modulo  arithmatic 
Conversion  from  integer  to 

real 
Transfer  of  sign 
Express  2  real  argument  in 

complex  term 
Obtain  the  conjugate  of  a 

complex  argument 
Integer  to  real  conversion 
Obtain  imaginary  part  of  a 

complex  argument 
Obtain  positive  difference 

of  2  numbers 


Ref:   IBM  FORTRAN  IV  LANGUAGE  pp.  118-123 
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5.5 


A  SAMPLE  PROGRAM  TO  ILLUSTRATE  CINGLF/DOUBLE  PRECISION 
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C* 
C 

c 

c 
c 

r 
C 

c 
c 
c 
c 
c 
c 
c 


DOUBLE  PRECISION  FUNCTION  GGBIN 
FUNCTION  GGBIN  (ISEED,  N,  F) 


(ISEED,  N,  F) 


RANDOM  DEVIATE 


FUNCTION     -  GENERATE  ONE  BINOMIAL  PSEUDO 
USAGE        -  FUNCTION  GGQIN  (ISEED,  N,  P) 

GGBIN-  RESULTANT  FLOATING  POINT  DEVIATE 
PARAMETERS   - 

ISEED-INTEGER  IN  THE  RANGE  (I,  2147483647).  ISEED  IS 
USED  TO  INITIATE  GENERATION  AND,  ON  EXIT,  IS 
REPLACED  BY  A  NB7  SEED.  (INPUT) 
N     -  BINOMIAL  PARAMETER  (MUST  BE  A  NON-NEGATIVE 

INTEGER)  (INPUT) 
P     -  BINOMIAL  PARAMETER  (MUST  BE  IN  THE  INCLUSIVE 
(0,1)  RANGE)   (INPUT) 

-  (ENCLOSE  LITERATURE  REF.) 

-  SINGLE 


REFERENCES 
C*PRECISION 

^  PRECISION 
SUBPROGRAMS 
AUTHOR 
LAST  UPDATE 


C 
C 

c 
c 
c** 


-  DOUBLE 

-  GGNOF,GGUBF,MERFI,UERTST 
-IMSL 

-f^RCH  22,1978 


C* 
C* 

c* 


200 


r 


IMPLICIT  REAL*3  (A-H,  O-Z) 


RSPID3/. 102 332670794 64 80D1/ 
CONl/-. 1166 335 397324 4 24D-1/ 
ONEP3/.133  33  3  3  33  3  3  33  3  3  3D1/ 
P3/0.3  33  3  33  3  3  33  3  33  333D-01/ 

RSQ1H/.7071068DQ/ 


DATA 

DATA 

DATA 

DATA 

DATA 

DSQRT(X)  =  SQRT(X) 

DFLOAT(I)  =  FLOAT(I) 

DERFC(X)   =  ERFC(X) 

GGBIN  =0D0 

NS 

PS 

IF 


IF 
NS 
IF 

210  NS 


220 


GO  TO  250 


NE.O)  GO  TO  210 


230 


=  M 

=  P 

(NS.LT. 15) 

IS  N  ODD 

(M0D(NS,2) 

=  NS  -  1 

(GGUBF(ISEED) .LE.PS)  GGBIN  =  GGBIN+lDO 

OBTAIN  THE  MEDIAN  OF  N  UNIFORM  DEVIATES 

=  NS/2 

OBTAIN  NORMAL  DEVIATES 
A  =  GGNOF(  ISEED) /DGQRT(ONEP3*nFLOAT(NS-i-lD0) -P3 
A  =  ( . 5D0*DERFCL-RSQin*A) ) *RSPID3+C0N1 
IF  (A. LE.PS)  GO  TO  2  40 
PS  =PS/A 
GO  TO  200 


24) 


UPDATE  COUNT  OF  POINTS  LESS  THAN  F 
240  GGBIN  =  GGBIN+DFL0AT{NS+1) 
PS  -  {PS-A)/(1D0-A) 
GO  TO  200 

COUNT  UNIFORM  DEVIATES  LESS  THAN  P 
250  IF  (NS.EQ.O)  GO  TO  270 
DO  260  J  =  K,NS 

IF  (GGBF(ISEED.LE.PS)  GGBIN=  GGBIN  +1D0 
260  CONTINUE 

270  RETURN 

END 
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APPENDIX  B 


TEST  PROBLEM  FOR  V-L  SEPARATIONS 
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1.   Demethanizer 
Total  stages 
Condenser 
Reboiler 
Exchanger 
Column  pressure 
Feed 


13 

No 

Yes,  stage  13 

yes,  stage  7 

3500  psia 

P  '   350.0  psia,  bubble  point  at  stage  1 

(top  stage) 


Component  Lb  moles/hr 


"2 

0.490 

COj 

3.280 

CH4 

347.8 

<^2H6 

90.67 

=3H3 

51.09 

i-C^ 

12.87 

n-C^ 

13.38 

i-Cj 

4.87 

n-Cc 

3.54 

"-=6 

3.2 

"-=7 

6.4 

537.6 


Bottoms:       182.62  lb  moles/hr  (   91. 96°?) 
Distillate:    355.00  lb  moles/hr  (   -127. 6°F) 
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2.   Demethanizer 


Total  stages 

25 

Condenser 

No 

Reboiler 

Yes, 

stage 

25 

Exchanger 

Yes, 

stage 

11. 

Cooler 

:  X 

Duty  = 

-113.000  3tu/hr 

Colmn  pressure 

• 
• 

98.0 

psia 

Feed 

• 
• 

1 

2 

P,  psia 

98.0 

98.0 

T,  Op 

dew  point 

50.0 

F,  Lb  moles 

5A 

ir 

330. ( 

D 

440.0 

Stage 

20 

1. 

Composition  (Mole  Fraction) 


CH4 

C2H6 
C3H8 

^-^4Hio 

^-^4Hio 
n-Cg 


0.1133 
0.0267 
0.0600 
0.5667 
0.2000 
0.0333 


1.0 


Bottoms:   698.5  lb  moles/hr 
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^'   Wide  boiling  mixture  with  intermediate  components 
(Boston,  1977) 


Total  stages 

Condenser 

Reboiler 

Exhanger 

Reflux  ratio 

Column  pressure 

Feed 

Pf  psia 
T,  Op 

F,  Ibmoles/hr 

Stage 

Composition 


20 

Yes,  Stage  1.   Total 

Yes,  Stage  20 

No 

4:1   Saturated  Liquid. 
19.7  psia 

14.7 

dew  point 

100.0 

9 

(mole  fraction) 


n-C 


4H1O 


n-C5Hi2 
"-^7Hi6 

^-^5H20 
n-C^0H22 


0.300 
0.100 
0.200 
0.100 
0.300 


Bottoms : 


50.0  Ibmoles/hr 
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Total  stages    : 

20 

Condenser      • 

Yes,  Stage  1.   Total 

Reboiler       : 

Yes,  Stage  20 

Exhanger       : 

No 

Reflux  ratio    : 

200:31  Saturated  Liquid. 

Column  pressure: 

100.0  psia 

Feed 

P/  psia 

100.0 

T,  Op 

bubble  point 

F,  Ibmoles/hr 

100.0 

Stage 

10 

Composition 

(mole  fraction) 

<^2H6 

0.30 

=3H8 

0.30 

"-<^12H26 

0.40 

Bottoms: 

69.0  Ibmoles/hr 

5.   Water-acetone 
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Total  stages 

Condenser 

Reboiler 


Exhanger 
Reflux  ratio 


38 

Yes,  Stage  1.   Total 

No.  During  the  test  runs,  reboiler  was 
included  in  order  to  compensate  for 
differences  in  calculations  of  steam 
properties. 

No 

1.3:1   Saturated  Liquid. 


Column  pressure:   16.0  psia 
Feed 

Pf  psia 

T,  Of 

F,  Ibmoles/hr 

Stage 

Composition 


16.0 

bubble  point 

770.25 

27 


2 

80.0 

350.0 

38 


acetone 
water 


211.588 
558.662 


0.0 
350.0 


Distillate: 


200.0  Ibmoles/hr 


Physical  Properties 
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Antoine's  equation 
where 


In  Pi  =  Ai  +  Bi(T  +  Ci) 
T  is  in   K 


i 

A 

B 

C 

acetone 

11.6694 

-3818.33 

-45.958 

water 

9.3751 

-2568.21 

-55.361 

Wilson's  equation  coefficients 

acetone 
acetone  — 

water  0.4167 


water 
0.1603 


6.   C2  Splitter 
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Total  stages 
Condenser 
Reboiler 
Exhanger 
Reflux  ratio 

Column  pressure 
Feed 

Pr  psia 

T,  Op 

F,  Ibraoles/hr 

Stage 

Composition 


50 

Yes,  Stage  1.   Total 

Yes.  Stage  50. 

No 

3:1   Saturated  Liquid. 
150.0  psia 

150.0 

bubble  point 

250.0 

25 

(moles/hour) 


CH4 

^2H4 
^2H6 
^3H8 
^4Hio 


50.0 
100.00 
110.00 

30.00 
5.00 


Bottoms : 


145.0    Ibmoles/hr 


7.   Amines  Column 
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Total  stages 

Condenser 

Reboiler 

Exhanger 

Reflux  ratio 

Column  pressure 

Feed 

P,  psia 

T,  Op 

F,  Ibmoles/hr 
Stage 
Composition 


47 

Yes,  Stage  1.   Total 

Yes,  Stage  47. 

No 

6:1  Saturated  Liquid. 

16.0  psia 

1  2 

189.69  269.69 

77.0  bubble  point 

400.0  100.1 

7  17 

(moles/hr) 


water 

MMA 

DMA 

TMA 


399.2 

0.8 
0.0 
0.0 


0.0 
52.58 
30.79 
16.63 


Distillate: 


16.63   Ibmoles/hr 


Physical  Properties 
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Antoine's  equation 
where 


T  is  in   K 


water 

monomethyl  amine 
dimethyl  amine 
trimethyl  amine 


A 

11.6694 

10.8797 

10.4926 

9.6276 


B 
-3818.33 
-2685.34 
-2685,56 
-2475.93 


C 

-45.958 

-20.729 
-25.650 

-18.925 


Wilson's  equation  constants 

Water        mma 
Water  —       0.72390 

MMA         1.75880 
DMA         0.21680      1.08340 
TMA         0.6830       0.00075 


DMA 

TMA 

1.2923 

0.64310 

0.7169 

2.89920 

— 

0.41155 

1.71901 

„,„ 
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8.   Extractive  distillation  with  furfural 


Total  stages 

Condenser 

Reboiler 

Exhanger 

Column  pressure 

Feed 

P,  psia 

T,  Op 

F,  Ibmoles/hr 

Stage 

Composition 
Case    1, 

1,3-butadiene 
n-butane 
i-butene 
trans-2-burene 
cis-2-butene 
1-butene 
water 
furfural 
Ca  s  e   2,3,4 

water 
fur  fual 
Pressure,    top 
Pressure,    bottom 


15 

No 

Yes,  Stage  15. 

No 


top  =  65.0  psia,   reboiler  =  70.0  psia 


1 
64.0 

bubble   point 
100.0 
2 


2 

67.5 

bubble  point 

10.1 

8 


0.35 
0.03 
0.03 
0.07 
0.07 
0.45 


1.0 

0.1,  0.2,  0.3 
0.9,  0.8,  0.7 
80.0,  90.0,  100.0 
85.0,  95.0,  105.0 


Bottoms : 


n4.n  Ibmoles/hr 
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9. 


Column  with  a  lot  of  components  and  a  large  number  of  stage 


Total  stages 
Condenser 


40 


Yes,    stage    1.      Partial.      Total  product 
rate-1508.0    lb   mole/hr.      Vapor   rate=108,0 
lb  moleAic. 
yes,    stage  40. 
NO 

3.6.1  (to  total  overhead  product) 

Saturated  liquid. 

Column  pressure:   Condenser  (stage  1) =115.0  psia, 

Stage  2  =  120.0  psia,  reboiler=12 . 5  psia. 


Reboiler 

Exchanger 
Reflux  ratio 


Feed: 
Pf  psia 
T,  Op 

F,  lb  moles/hr 
Stage 
Composition 


127.25 

dew  point 
3193.89 
31 


H, 


N. 


CH, 


•2H6 


CO, 


HoS 


1.214 

6.053 

14.395 

87.737 

5.676 


3.286 
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^3H8 

^"^5Hi2 

cycle-Cj 

2,2di-m-C. 

2,3di-m-C^ 

2-meth-Ce 

3-meth-Ce 

"■^6Hi4 
m-cyclo-Ce 


467.158 
237.193 
685.860 
333.145 
458.949 
74.875 
3.981 
94.683 
120.151 
95.041 
269.508 
234.981 
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10.   Column  with  a  lot  of  components. 

This  is  a  modification  of  the  example  9.   The  number  of 
steps  is  halved.   Everything  else  is  the  same. 

Total  stages:   20 

Feed  stage:     15 

This  example  provides  an  insight  to  how  the  execution  time 
changes  with  the  number  of  steps. 
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11.   Column  with  a  side-draw 


Total  stages 
Condenser 
Reboiler 
Exchanger 
Side  draw 


39 


Yes,  stage  1.   Total 
Yes,  stage  39. 
No 

Yes,    stage   32.      Vapor   phase 
Rate   =   15.57    lb  moles/hr. 
75.9:    301 

Column  pressure:   Condenser  21.7  psia, 

Reboiler   27.7  psia. 


Reflux  ratio 


Feed 
P,  psia 

T,  Of 

F,  lb  molesAr. 

Stage 

Composition 
benzene 
toluene 
biphenyl 


24.67 

bubble  point 
330.22 
19 

301.93 
15.939 
13.353 


Bottoms: 


13.87    lb  moles/hr. 
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